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INTRODUCTION  AND  OVERVIEW 
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\ 

\ 

[ 1.1  INTRODUCTION 

^ . Introduction  of  TRADOC  System  Managers  (TSMs)  to  the  development  of 

major  Army  systems  comes  at  a time  when  the  total  systems  acquisition 
process  is  undergoing  major  change.  The  Training  System  Development  and 
Acquisition  Model  set  forth  in  this  guide  attempts  to  incorporate  training 
I acquisition  developments  into  the  total  system  Life  Cycle  System  Management 

! Model  (LCSMM).  As  many  of  the  activities  and  policies  are  new  and 

t 

[ little  information  exists  about  how  activities  are  to  be  carried  out, 

i 

there  are  significant  gaps  in  the  specific  implementation  procedures  to 
be  followed  for  the  acquisition  of  training  for  any  specific  major  system. 
Therefore,  users  are  cautioned  that  this  document  can  serve  only  as  a guide 
and  should  not  be  viewed  as  a definitive  handbook  on  training  acquisition. 

I 

Policy  and  procedures  that  will  allow  such  specific  guidance  will  come 
through  additional  development  and  experience  as  system  acquisition  efforts 
proceed.  This  model  and  procedural  guide,  then,  is  viewed  by  its  developers 
as  "Block  1,"  the  starting  point  from  which  considerable  expansion  and  revi- 
' slon  will  be  required  to  produce  a final  TSM  Handbook.  Critical  review  and 

comments  on  its  organization  and  content  are  invited. 

1.2  OVERVIEW 

1.2.1  Purpose.  This  guidebook  describes  training  acquisition  acti- 
vities for  major  systems  as  prescribed  by  Army  policy  for  acquisition  of 
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materiel  systems.  The  primary  guidance  documentation  for  this  work  includes 
Army  Regulation  No.  1000-1  (effective  1 September  1977)  Basic  Policies  for 
Systems  Acquisition,  and  Army  Regulation  No.  1000-'’  (final  draft  version 
dated  17  January  1977  pending  publication  of  the  above  AR-1000-1)  Operating 
Policies  for  Systems  Acquisition  by  the  Department  of  the  Anay. 

1.2.2  Applicability  and  Scope. 

a.  The  materials  in  this  guidebook  are  directed  to  developers 
(primarily  TSM  offices)  of  training  subsystems  for  major 
materiel  systems.  While  much  of  the  information  presented 
here  is  also  applicable  to  training  acquisition  for  non- 
major systems,  no  attempt  has  been  made  to  deal  with  variants 
from  the  major  systems  acquisition  model. 

b.  This  guidebook  treats  the  training  acquisition  process  from 
the  concept  formulation  stage  forward,  through  Initial 
Operational  Capability  (IOC).  Training  development  and 
acquisition  activities  are  organized  under  11  major  headings, 
each  descriptive  of  a major  set  of  activities  in  the  total 
system  acquisition  process  in  general  correspondence  with 
those  in  the  Life  Cycle  Systems  Management  Model  (LCSMM). 

c.  The  material  in  this  guidebook  is  primarily  descriptive. 

The  intent  is  to  integrate  the  training  acquisition  process 
with  the  total  system  acquisition  process  through  interpreta- 
tion of  existing  and  proposed  Army  policies  and  procedures, 
and  projection  of  required  training  development  and  acquisi- 
tion activities  within  the  guidance  provided  by  Army  policies 
and  procedures.  It  should  be  noted  that  this  process  of 
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Interpretation  and  projection  may  exceed  explicit  provisions 
for  some  activities.  Developers  are  encouraged  to  assist  in 
the  identification  of  such  activities  and  are  further  encour- 
aged to  exercise  critical  judgment  in  evaluating  the  guidance 
provided  herein. 

1.2.3  The  Systems  Approach.  Training  acquisition  for  major  systems 
occurs  within  the  context  of  the  total  systems  acquisition  process.  As  an 
Integral  part  of  the  total  developmental  effort,  training  subsystem 
acquisition  activities  must  be  closely  coordinated  with  the  activities  of 
other  subsystem  developmental  efforts  at  each  stage  in  the  developmental 
process.  Each  siibsystem  developer,  the  TRADOC  Systems  Manager,  and  the 
Project  Manager  must  have  a good  working  knowledge  of  the  total  system 
acquisition  process,  and  the  role  of  each  major  participant  in  the  develop- 
mental effort. 

Major  military  systems  are  complex,  sophisticated  and  expensive. 

The  process  to  conceive,  design  and  develop,  and  field  systems  is  long 
and  exacting.  New  systems  must  utilize  technology  at  the  leading  edge  to 
meet  their  design  requirements.  The  acquisition  process  is  complex  and 
requires  state-of-the-art  management,  coordination,  and  communication 
techniques  to  produce  maximally  useful  and  cost-effective  systems  in  a 
mlrlmal  time  frame.  To  be  efficient  and  productive,  a system  acquisition 
process  must  display  the  following  characteristics: 

a.  Organization  - All  activities  must  be  clearly  specified, 
with  authority  and  responsibility  for  each  clearly 
delineated.  While  the  hierarchy  for  controlling  the 
process  should  be  as  flat  as  possible  (i.e.,  few  levels 
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or  layers  of  management),  this  requirement  must  be  balanced 
against  the  span  of  control  and  dispersion  of  activities 
reasonable  to  any  one  individual  or  organization. 

b.  Capabilities  - The  capabilities  required  to  perform  all 
tasks  must  be  present  in  the  form  of  trained  and  experienced 
personnel,  fiscal  resources  allocated  properly,  and  tech- 
nology available  to  carry  out  required  activities. 

c.  Guidance  - Specific  goals  and  objectives  are  necessary  to 
keep  the  process  on  target  and  to  provide  criteria  for 
measuring  progress.  This  is  a continuing  activity  in  which 
goals  are  redefined  in  terms  of  changing  needs,  objectives 
become  refined  and  operationalized  through  planning  and 
development,  and  operational  criteria  are  developed  and 
modified  in  terms  of  the  identified  capabilities  and  con- 
straints of  the  developing  system. 

Secondary  level  guidance  in  the  form  of  regulations,  proce- 
dures, and  other  guidance  documentation  is  necessary  to 
assure  a uniform  and  orderly  developmental  effort.  Such 
guidance,  to  the  extent  that  it  is  applicable,  complete, 
and  specific,  provides  a structure  within  which  the 
acquisition  process  can  take  place,  and  fosters  the  com- 
munication and  coordination  among  elements  necessary  for 
smooth  operation.  To  the  extent  that  this  documentation 
also  contains  criteria  for  judging  the  processes  and 
products  of  the  effort,  then  that  function  will  be 
facilitated. 
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1.2.4  Requirements  of  the  Systems  Approach.  The  Army  is  committed 
to  the  "System  Approach"  for  the  development  and  acquisition  of  major 
materiel  items.  The  term  "system"  implies  the  existence  of  several  entities 
bonded  together  to  produce  a higher  level,  unified  entity.  Implicit  to 
this  definition  is  the  concept  that  to  function  properly  each  component  of 
the  total  system  must  make  its  Intended  contribution  to  the  total  system 
effort.  Conversely,  failure  of  any  component  will  degrade  total  system 
functioning.  Recognition  and  acceptance  of  the  interdependence  among  sub- 
systems should  lead  to  an  awareness  of  the  need  for  an  integrated  system 
development  effort. 

However,  recognition  of  this  need  is  not,  alone,  sufficient.  For 
almost  any  system  development  effort,  time  and  money  constraints  are 
severe.  The  realistic  goal  should  not  be  "to  get  the  best  system,"  but 
should  be  "to  get  the  most  effective  system  for  the  resources  expended." 

This  In^lles  that  system  developers  can  deal  with  these  issues: 

a.  Establish  performance  objectives  for  the  system  as 
a whole. 

b.  Identify  subsystem  requirements  that  Impact  total 
system  performance. 

c.  Identify  the  technology,  costs,  and  time  associated 
with  developing  each  subsystem. 

d.  Control  the  developmental  process  to  ensure  that 
critical  requirements  of  each  subsystem  are  satis- 
fied, while  maintaining  the  flexibility  to  redirect 
efforts  to  assure  that  total  system  requirements  are 
met. 
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Each  of  these  Issues  constitutes  a set  of  "problems"  to  be 
"solved"  in  the  course  of  system  development.  At  a global  level,  the  LCSMM 
provides  guidance  for  attacking  these  problems.  A multitude  of  DOD  and 
Army  Regulations,  Military  Specifications  and  Standards,  Army  Pamphlets, 
Circulars,  Manuals,  Handbooks,  Guides,  and  other  documents  provide  guidance 
at  varying  levels  of  specificity.  Still,  system  development  efforts  are 
not  meeting  their  stated  objectives. 

1.2.5  Common  Developmental  Problems.  While  it  is  not  the  purpose 
of  this  guide  to  "rehash"  the  problems  encountered  in  system  development, 
it  is  useful  to  identify  how  failure  to  follow  system  development  "rules" 
may  affect  the  developmental  process,  and  to  identify  "corrective  measures" 
which  should  be  built  into  the  acquisition  process. 

a.  Excessive  Development  Time.  With  the  passage  of  time  the 
"values"  of  a number  of  factors  making  up  the  rationale 
for  a system  will  change.  The  philosophy  guiding  the 
development  of  the  system  need  (MENS) , is  based  on  the 
projected  threat  at  a specified  future  time.  The  system 
is  to  be  tailored  to  meet  the  threat  and  "fit"  the  total 
inventory  during  a slotted  time  frame.  Systems  not  fielded 
in  this  slot  may  be  obsolete  in  terms  of  their  capability  to 
meet  that  threat. 

As  technology  advances,  new  developments  provide  the  capa- 
bility for  new  concepts.  Shorter  development  time  makes  it 
easier  to  get  new  technology  "into  the  pipe"  when  resources 
are  limited. 

Inflation  and  ongoing  developmental  costs  associated  with 
time  will  erode  acquisition  budgets  quickly.  Conceivably  a 
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two-year  delay  in  a "buy  decision"  for  a large  system 
could  totally  invalidate  the  cost-effectiveness  basis  upon 
which  the  acquisition  decision  was  originally  made, 
b.  Poor  Integration  of  Subsystem  Developments.  While,  con- 
ceptually, system  development  is  viewed  as  an  integrated, 
coordinated  effort  directed  toward  a single  common  goal, 
the  reality  is  that  a multitude  of  individual  activities 
are  underway — each  with  its  own  problems,  its  own  pace,  and 
its  own  direction.  A successful  system  is  not  made  up  from 
many  "optimized"  components,  but  is  a masterpiece  of  com- 
promises . 

Since  it  is  not  realistic  for  the  proponent  of  each  system 
component  to  be  conversant  with  the  way  his  component  will 
best  fit  into  the  overall  system,  it  is  likely  that  he  will 
attempt  to  Influence  system  design  to  optimize  his  component 
in  terms  of  its  Inherent  needs,  and  attempt  to  minimize 
the  "chipping  away  at  its  configuration"  by  proponents  of 
other  system  components. 

Where  total  system  criteria  are  solid  and  technology  and 
practice  allow  a clear  "audit  trail"  to  be  established 
between  each  component  and  total  system  effectiveness, 
then,  theoretically,  decisions  about  each  component  can 
be  based  upon  a rational  trade-off  analysis  in  terms  of 
total  system  criteria.  Often,  however,  it  is  not  possible 
to  operate  in  a purely  objective  manner,  with  decisions 
based  upon  valid  empirical  Information.  Then,  the 
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decision  process  Is  significantly  altered  from  the 


1 

i 


ideal  model.  Some  of  the  factors  here  are: 

(1)  Tradition  - Components  of  the  system  that 
historically  have  driven  development  continue 

to  receive  priority  until  it  is  demonstrated  that 
a different  hierarchy  is  appropriate. 

(2)  Technology  - Components  for  which  "credible" 
developmental  technology  and  procedures  exist  will 
drive  development  because  the  proponents  can  supply 
information  to  "fill  in  the  boxes"  in  the  system 
decision  model,  while  other  proponents  will  only 
provide  less  credible  guesses  or  estimates  of  parame- 
ters upon  which  decisions  are  based. 

(3)  Visibility  and  Concreteness  - It  is  much  easier  to 
understand  and  work  with  the  concept  of  a piece  of 
equipment  than  it  is  a logistics  support  system. 

(4)  Sequence  - One  view  of  the  development  process 
holds  that  the  equipment  development  should  take 
precedence  over  other  subsystems,  with  subsequent 
development  of  these  components  tailored  to  the 
needs  of  the  hardware  system.  This  view  loses 
some  credence  when  hardware  design  requirements 
Imposed  on  other  subsystems  exceed  reasonable 
capabilities  for  these  subsystems. 

(5)  Cost  - Actual  (or  perceived)  high  developmental 
costs  or  end  item  costs  tend  to  receive  emphasis 
in  the  developmental  program.  This  is  especially 
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true  where  the  costs  are  associated  with  a visible 
unit,  such  as  a tank,  computer  system,  or  aircraft. 
These  Items  may  receive  a disproportionate  share  of 
attention,  unless.  Instead  of  developmental  and 
acquisition  costs,  total  life  cycle  costs  are  used 
as  the  yardstick  governing  priorities  for  allocating 
funds  and  effort  In  the  overall  system  development. 
However,  as  stated  above  (Points  2 and  3)  the  re- 
alignment of  priorities  requires  realistic  and 
credible  data  about  the  various  system  components. 

(6)  "Timeliness”  - In  order  for  any  subsystem  to  share 
fully  in  driving  the  developmental  process,  data 
concerning  its  "needs"  and  its  interaction  with  other 
system  elements  must  be  available  at  those  points 
where  critical  system  decisions  are  made.  This 
means  that  early  planning  and  design  activities  must 
consider  all  critical  elements,  and  each  element 
must  be  developed  to  the  point  where  trade-off 
analyses  will  consider  the  issues  which  impact  the 
total  system.  The  number  of  "unknowns"  which  must 
be  dealt  with  In  early  development  make  this  probably 
the  toughest  systems  development  task,  but  it  Is 
absolutely  essential  within  the  systems  approach. 

To  summarize,  if  the  systems  concept  is  to  drive  the  acquisition 
process,  then  the  overall  criterion  for  development  is  the  contribution 
of  each  activity  to  overall  system  effectiveness.  To  achieve  this  goal 
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to  achieve  the  best  possible  compromise  among  subsystems  to  maximize  total 
system  effectiveness.  This  can  only  be  achieved  when: 

a.  All  subsystems  are  developed  concurrently. 

b.  The  work  on  each  subsystem  is  directed  to  identifying 
its  potential  contributions  and  constraints  to  the 
total  system  effort. 

c.  Realistic  and  credible  data — empirically  derived  data — 
are  developed  and  utilized  in  the  system  analysis  model 
from  which  system  decisions  are  derived. 

Finally,  cost  and  time  constraints  normally  set  the  upper  boundaries 
which  limit  system  goals.  Realistically,  the  goal  should  not  be  to  acquire 
the  best  possible  system,  but  to  acquire  the  most  effective  system  for  the 
resources  available. 

1.2.6  Modifications  to  the  Systems  Acquisition  Process.  Several 
policy  and  procedural  changes  are  now  being  implemented  to  upgrade  system 
acquisition  efforts. 

a.  Restructuring  the  LCSMM.  One  "cause"  of  excessive  system 
development  time  is  perceived  to  be  the  structure  of  the 
LCSMM.  It  is  viewed  as  somewhat  conservative,  requiring 
too  many  Iterations  of  the  basic  steps  of:  Plan  - Approve  - 
Develop  - Test.  Revisions  to  the  LCSMM  will  essentially 
remove  one  developmental  iteration  by  compressing  the 
activities  of  Full-Scale  Development  and  Production  and 
Deployment  into  one  phase.  These  changes  will  increase 
the  scope  of  activities  earlier  in  the  development  process 
as  well,  with  DT/OT  II  (and  ASARC  III)  assuming  some  of 


1-10 


the  responsibilities  formerly  attributed  to  DT/OT  III 
(and  ASARC  IV). 

b.  "Enforcing"  Developmental  Progression  Criteria.  There 

is  some  evidence  that  systems  under  development  have  been 
allowed  to  pass  from  one  level  or  phase  of  development  on 
to  the  next  without  fully  meeting  the  criteria  established 
for  the  previous  stage.  Revisions  to  the  LCSMM  should 
bolst'^r  procedures  for  determining,  at  each  developmental 
stage,  whether  or  not  all  criteria  have  been  met,  and 
provide  guidance  that  will  direct  reentrance  into  the 
development  process  to  allow  additional  work  and  retesting 
as  required  prior  to  moving  into  the  next  stage  of  develop- 
ment. As  a minimum,  LCSMM  revisions  should  emphasize  the 
Importance  of  testing  in  terms  of  total  system  objectives 
and  goals. 

Failure  to  meet  established  criteria  is  probably  not  the 
only  issue  here.  It  is  very  likely  that  some  of  the  prob- 
lems encountered  later  in  the  developmental  process  are 
due  to  Incomplete  testing  at  earlier  stages.  This,  in 
turn,  is  likely  to  have  been  a result  of  less  than  ade- 
quate criterion  development  procedures  which  result  in 
1)  "holes" — areas  for  which  no  criteria  are  developed, 
and  2)  Inadequate  criteria — criteria  which  are  not  stated 
in  sufficiently  specific  terms  to  allow  definitive  test- 
ing, are  not  valid,  (l.e.,  do  not  represent  critical 
system  objectives),  or  are  not  amenable  to  measurement. 


c.  Integration  of  Training  and  Other  Support  Subsystems 
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Into  the  Total  System  Developmental  Effort.  Close  coor- 
dination among  the  proponents  for  Personnel,  Logistics 
and  Training  is  essential  to  achieve  optimum  human  per- 
formance. There  are  four  factors  to  be  considered  in 
ensuring  adequate  job  performance:  design,  documentation, 
selection,  and  training. 

(1)  Design.  Equipment  and  job  procedures  should  be 
designed  to  minimize  operator  and  maintenance 
requirements. 

(2)  Documentation.  Technical  manuals  and  other  per- 
formance aids  should  be  made  as  useful  as  possible 
and  targeted  to  the  level  of  the  greatest  user 
population. 

(3)  Selection.  Incumbents  should  possess  the  basic 
skills  and  knowledge  requisite  to  job  performance 
requirements. 

(4)  Training.  Training  should  be  limited  to  those 
aspects  of  the  job  which  are  not  commonly  found  in 
the  entering  level  incumbent's  repertoire,  should 
be  directly  related  to  job  performance  requirements, 
should  be  presented  in  modes  most  effective  to  the 
content/learner , etc. 

Current  conditions  do  not  allow  these  four  factors  to 
vary  freely.  The  body  of  skills  and  knowledge,  including 
demonstrared  learning  skills,  possessed  by  the  majority 
of  incoming  recruits  is  limited.  Turnover  rates  for 
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lower-level  personnel  preclude  extensive  training  because 
of  cost.  Weapons  systems  are  complex  and  sophisticated 
with  demanding  operator,  maintenance,  and  support  require- 
ments. Documentation  is  not  designed  well  for  on-the-job 
use,  is  targeted  to  a higher-level  audience,  and  in 
many  cases  is  incomplete,  outdated,  and/or  not  specific 
enough. 

Training  programs,  for  the  most  part,  are  outmoded  in 
that  they  do  not  take  advantage  of  the  most  effective 
Instructional  technology,  and  are  not  systematically 
developed  to  ensure  job  relatedness.  The  result  is  an 
inefficient  training  program  resulting  in  Inadequately 
qualified  job  Incumbents.  The  cumulative  result  of  these 
deficiencies  is  a considerable  gap  between  the  potential 
operational  capability  of  our  fielded  forces  and  the 
actual  capability  level  at  which  they  are  currently 
operating.  (Examples:  Weapons  that  many  soldiers  can- 
not fire  with  the  expected  degree  of  accuracy;  complex 
equipment  with  high  downtime  rates  because  maintainers 
do  not  have  the  skills  to  repair;  studies  showing 
exchange  of  serviceable  parts  indicating  inability  to 
troubleshoot;  development  of  TM  supplementary  materials 
to  enable  job  incumbents  to  function.) 

The  problems  and  inefficiencies  described  above  have  provided  the 
Impetus  for  the  policy  and  procedural  changes  now  being  Instituted.  From 
a training  viewpoint,  these  changes  should  impact  the  system  acquisition 
process  and  especially  the  training  acquisition  process  as  follows. 
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personnel  and  other  support  subsystem  concerns  are  to  be 
introduced  early.  This  will  allow  capabilities  and  con- 
straints from  these  areas  to  Impact  total  system  design, 
and  will  also  allow  early  planning  to  provide: 

(1)  Rationales  for  funding  training  development. 

(2)  Identification  of  training  issues  to  be  resolved 
as  part  of  the  validation  process,  e.g. , high- 
risk  tasks. 

(3)  Longer  lead  times  for  training  device  development. 

(4)  Embedding  training  and/or  test  devices. 

It  should  be  noted  that  changes  to  the  acquisition  docu- 
mentation emphasize  the  importance  of  these  activities, 
but  do  not  provide  the  "wherewithal"  for  their  accomplish- 
ment . 


The  ITDT  program  is  Intended  to  make  Job  Incumbents 
(especially  maintainers)  more  self-reliant.  This  is  to 
be  accomplished  by  1)  providing  documentation  (TM)  designed 
for  use  on  the  job,  and  2)  integrating  training  develop- 
ment and  documentation  development  processes.  Under  the 
ITDT  concept  it  is  Intended  that  the  documentation  serve 
as  a principal  vehicle  for  training  (as  well  as  use  on 
the  job)  and  that  the  principle  of  adjunctive  training  be 
used  extensively.  Adjunctive  training  materials 
will  introduce  the  student  to  the  TM  and  guide 
him  through  the  use  of  these  materials.  The  central 
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principle  of  adjunctive  training  is  the  extensive  use  of 
the  TM  as  the  primary  instructional  resource  in  the 
instructional  or  learning  process. 

The  ITDT  requirement  will  impact  the  training  acquisition 
process  by  requiring  early  developmental  work  to:  1)  Iden- 
tify mission  critical  and  high  training  risk  tasks  as  early 
as  possible;  2)  conduct  the  task,  behavioral,  and  learning 
an  lyses;  and  3)  develop  and  validate  prototype  documentation, 
training  materials,  and  associated  training  devices  for  those 
tasks  for  verification  at  DT/OT  I.  This  requirement 
will,  in  turn,  place  demands  on  the  training  developers 
to  do  the  necessary  preliminary  work  and  planning  to 
ensure  that  provision  for  these  activities  is  included  in 
the  LOA  and  Validation  Phase  contracts, 
c.  Development  of  a Master  Training  Plan.  All  the  elements 
of  the  training  subsystem  should  be  Integrated  into  a 
single  document.  This  training  plan  is  the  Individual/ 
Collective  Training  Plan  (ICTP).  During  the  conceptual 
stage  the  first  draft  of  the  plan  will  be  the  OICTP 
(Outline  ICTP).  The  OICTP  will  be  updated  and  refined 
for  the  Concept  Formulation  Package  (CFP)  and  the  Outline 
Development  Plan  (ODP) . As  the  plan  matures  through 
DT/OT  I and  ROC,  it  will  be  revised  and  incorporated 
into  the  Development  Plan  (DP)  as  the  ICTP. 

The  purpose  of  the  ICTP  is  to  have  a single  or  "master" 
training  document  which  addresses  all  training  issues. 

This  document  will  provide  the  central  point  from  which 
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the  trainer's  position  on  the  diverse  activities  affect- 
ing training  will  emanate.  Portions  of  the  ICTP  will 
also  be  integrated  into  other  acquisition  documentation 
(e.g.,  the  training  test  plan  will  be  incorporated  into 
the  total  system  coordinated  test  plan). 
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SECTION  2 

TRAINING  DEVELOPMENTS  MODEL 


2.1  APPROACH 

The  approach  for  constructing  the  training  subsystem  acquisition  model 
was  to  first  identify  the  essential  steps  for  identifying  training  needs  and 
training  developments,  and  then  integrating  these  activities  into  the  total 
Life  Cycle  System  Management  Model.  This  generalized  training  develop- 
ments model  is  presented  in  Figure  2.1. 

[Figure  2.1  about  here] 

A more  detailed  breakout  of  the  activities  in  each  block  is  contained 
in  Figures  2.2-2. 7. 

2.2  SYSTEM  CONCEPTS 

Block  1,  "System  Concepts"  portrays  the  initiating  conditions  for 
system  development. 

[Figure  2.2  about  here] 

The  system  need,  doctrine,  material  capability,  support  capability 
and  organization  all  come  together  to  generate  system  concepts  with  poten- 
tial for  neutralizing  the  threat.  In  the  life  cycle  model  these  activities 
comprise  the  material  concept  investigation,  the  initial  set  of  activities 
of  the  conceptual  phase. 

The  development  of  system  concepts  is  pursued  on  two  fronts: 

1)  criteria  for  system  performance  (operational  capability  objectives, 
or  science  and  technology  objectives,  and  capability  goals)  are 
generated  on  the  basis  of  the  level  and  nature  of  the  perceived  threat. 
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Figure  2.1.  Generalized  Training  Developments  Model:  Overview 
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Figure  2.2.  Block  1 System  Concepts 
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and  2)  potential  resources  are  marshalled  to  generate  effective  and 
efficient  system  solutions.  Components  of  the  resource  front  include: 
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a.  Doctrine.  The  body  of  knowledge  of  strategy  and 
tactics  which  will  govern  how  the  new  system  will  be 
employed. 

b.  Materiel/Software  Technology.  The  current  state-of- 
the-art  is  utilized  to  take  advantage  of  new  materials 
and  equipment  designs. 

c.  Personnel.  Capabilities  of  personnel  available  to  the 
service  are  projected  for  the  anticipated  life  of  the 
system,  in  terms  of  entering  skills,  tralnability, 
term  of  enlistment  and  retention,  and  numbers  available 
to  the  system. 

d.  Logistics.  Capabilities  of  the  support  organization 
to  maintain  and  supply  the  system. 

e.  Organization.  Guidance  to  ensure  the  system  will  mesh 
with  and  complement  other  systems  in  the  military 
Inventory. 

f.  Training.  Capabilities  of  the  proponent  schools  to 
develop  and  provide  training  for  the  operation  and 
maintenance  of  system  components. 

To  "harden"  the  system  concepts  into  a less  abstract  and  more  concrete 
form  these  concepts  must  be  "operationalized."  To  be  realistic, the  emerging 
system  designs  must  consider  not  only  the  potential  capabilities  of  each 
component  subsystem,  but  must  recognize  the  constraints  and  limitations 
of  each  as  well.  System  concepts  are  translated  into  system  descriptions 
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by  proceeding  from  statements  about  what  the  system  is  to  achieve  (goals, 
objectives)  to  statements  about  what  has  to  be  done,  i.e.,  who  or  what 
will  perform  various  system  functions.  These  statements  are  drawn  up 
within  the  context  of  scenarios,  (e.g.,  SCORES). 

2.3  FUNCTION  ANALYSIS  AND  TASK  LISTING 

The  activities  portrayed  in  Block  2 are  similar  to  elements  of  a 
Front  End  Analysis  (FEA)  performed  as  part  of  the  logistics  subsystem 
developmental  effort. 

[Figure  2.3  about  here] 

This  term  (FEA)  is  not  used  here  because  this  analysis  is  not  limited  to 
identifying  and  describing  maintenance  tasks.  The  objectives  of  this 
activity  are  to: 

a.  Develop  the  Mission  Profile. 

b.  Identify  human-machine  Interfaces. 

c.  Develop  an  initial  listing  of  tasks. 

d.  Within  this  listing,  identify  mission  critical  tasks. 

2.3.1  Mission  Profile.  The  mission  profile  consists  of  a list  of 

"tasks  and  conditions"  for  system  employment  in  military  operations.  Task 
statements  are  rated  (or  ranked)  in  terms  of  frequency  of  occurrence  and 
urgency.  A mission  profile  should  be  developed  for  each  system  alternative 
and  is  derived  from  the  operational  capability  objective  (OCO)  or  STOG  and 
the  system  description.  A "first  cut"  mission  profile  should  be  drafted 
at  the  system  concept  stage  and  this  rough  draft  version  refined  and  updated 
as  system  concepts  are  developed  and  translated  into  more  specific  functions. 

A key  input  from  the  mission  profile  to  the  development  process  is  guidance 
for  establishing  the  criticality  of  system  functions  and,  subsequently,  the 
criticality  of  tasks.  The  mission  profile  is  Included  in  the  LOA  as  "Annex  A." 
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Figure  2.3.  Block  2 Function  Analysis  and  Task  Listing 
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2.3.2  Function  Analysis.  This  step  In  the  system  development  process 
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Is  to  determine  how  various  system  objectives  are  to  be  accomplished,  and 
to  assign  these  functions  to  various  components,  sub-components,  and 
elements.  A part  of  this  step  Is  the  discrimination  of  those  functions 
best  performed  by  humans  from  those  to  be  performed  by  machines /equipment. 

At  this  level,  three  output  classes  are  appropriate: 

a.  Machine  functions 

b.  Human  functions 

c.  Man/machlne  (shared)  functions 

Shared  functions  are  critical  to  the  development  of  training  because  they 
Identify  prime  candidates  for  training  devices  and  simulators,  and  embedded 
testing  and  training  capabilities. 

It  Is  likely  that  much  of  the  system  will  not  be  sufficiently  developed 
at  this  point  to  allow  complete  specification  and  assignment  of  functions. 
This  function  analysis  and  allocation  step  should  Identify  gaps,  and  should 
be  especially  sensitive  to  gaps  at  the  man/machlne  Interface.  These  "missing 
areas"  of  the  system  which  cannot  be  analyzed  In  greater  detail  may  be 
Identified  as  unknowns  and  Included  In  the  LOA  as  Issues  requiring  further 
study  and  development. 

The  analysis  Is  Iterative,  and  the  added  degree  of  specificity  result- 
ing from  the  functional  analysis  should  permit  the  mission  profile  to  be 
updated.  This  update  may  then  be  used  to  rate  or  rank  the  criticality  of 
mission  functions. 

2.3.3  Interface  Analysis.  Shared  fimctlons,  which  by  definition 
Imply  heavy  Interaction  between  human  and  machine  components,  are  developed 
and  described  In  more  detail: 

a.  To  Identify  machine  design  parameters  related  to  human 
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functions,  (e.g. , locating  indicators  where  they  are 
visible  to  operators  of  associated  controls). 


b.  To  break  out  human  functions  to  a level  of  detail  suffi- 
cient to  identify  tasks. 

c.  To  develop  Interface  operating  parameters,  e.g.,  "sensing 
and  feedback  characteristics"  required  for  operators, 
control  characteristics,  and  other  operability  and  main- 
tainability characteristics  and/or  requirements,  redun- 
dancy, etc. 

The  Interface  analysis  provides  critical  Inputs  to  equipment  design 
and  establishes  the  framework  within  which  training  device  requirements 
can  be  generated.  Depending  upon  the  type  and  complexity  of  the  system, 
this  step  may  be  extremely  critical,  as  many  of  the  most  critical  and 
high  risk  tasks  will  occur  at  the  man/machine  interfaces.  The  capabilities 
of  the  expected  operator  population  must  be  factored  into  the  interface 
design. 

2.3.4  Initial  Task  Listing.  The  "human  functions"  and  (as  appro- 
priate) Interface  analyses  are  inputs  to  the  derivation  of  the  initial  task 
listing.  Essentially,  this  step  is  a restatement  of  functions  (what  must 
be  accomplished)  or  outcomes  into  a list  of  activities  which  must  be  per- 
formed in  order  to  achieve  the  system  objectives. 

The  initial  task  listing  is  a juncture  for  two  lines  of  activity  which 
follow.  The  initial  task  list  is  reviewed  and  culled  to  produce  a listing 
of  critical  tasks.  These  tasks  are  then  subjected  to  a relatively  inten- 
sive analysis.  The  remaining  tasks  are  analyzed  at  this  point  only  to  the 
degree  that  will  allow  a reasonable  estimate  of  training  requirements  to 
be  derived,  and  high-risk,  but  not  mission-critical,  tasks  identified. 
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2.4  JOB/TASK  ANALYSIS  AND  TRAINING  RISK  ANALYSIS 

Activities  in  Block  3 take  the  training  analysis  from  the  initial 
task  listing  to  a point  where  mission  critical/high  risk  for  training  tasks 
can  be  specified. 

[Figure  2.4  about  here] 

2.4.1  Job /Task  Analysis.  To  the  extent  possible,  tasks  are  broken 
out  into  sub-tasks  and  task  elements  to  a level  of  detail  that  will  permit 
inferences  to  be  made  about  behaviors  required  in  their  performance. 

2.4.2  Behavioral  Analysis.  The  detailed  task  analysis  Inputs  the 
behavioral  analysis.  Skills  and  knowledge  required  to  perform  the  elements 
of  each  task  are  identified  and  listed  in  behavioral  terms.  This  step 
completes  the  chain  of  analysis  from  the  system  function  level  to  a level 
at  which  individual  task  element  behaviors  are  specified. 

2.4.3  Training  Risk  Analysis.  The  concepts  of  training  risk  and 
mission  criticality  have  been  separated  in  the  developmental  process.  The 
rationale  for  this  being  that  the  criteria  are  independent  and  conceptually 
unrelated.  Mission  criticality  has  no  logical  bearing  on  the  level  of 
difficulty  of  task  performance  or  the  perceived  degree  of  uncertainty  about 
how  to  train.  The  purpose  of  the  training  risk  analysis  is  to  order  or 
rank  tasks  according  to  training  risk.  Some  candidates  for  training  risk 
criteria  might  be: 

a.  Level  of  skill  or  knowledge  required  or  proficiency 
level. 

b.  Complexity  (number  of  skills  and  amount  of  knowledge 
required) . 

c.  Training  "distance"  (the  "distance"  between  skill  and 

knowledge  levels  of  trainees  at  entry  level  and  the 

levels  required  for  proficient  performance). 
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d.  Skills  requiring  unusual  capabilities  or  abilities, 
those  not  particularly  abundant  in  the  typical  operator 
population. 

e.  Areas  in  which  skill  enhancement/development  tech- 
niques are  not  particularly  well  understood  or  train- 
ing techniques  are  not  well  developed. 

2.4.4  Mission  Criticality/Training  Risk  Matrix.  From  the  steps  above, 
rating  and/or  ranking ’of  tasks  on  two  sets  of  criteria  will  be  done.  Tasks 
are  assigned  to  cells  in  a critlcallty/risk  matrix.  Priorities  for  train- 
ing development  during  the  validation  phase  will  be  dependent  upon  the 
placement  of  tasks  in  the  matrix.  Critical,  high-risk  tasks  should  be 
listed  in  the  LOA  and  should  be  included  in  the  work  to  be  performed  as 
part  of  the  Validation  Phase  contractor  effort. 

2.5  TRAINING  REQUIREMENTS  AND  TRAINING 
DEVICE  REQUIREMENTS  ANALYSES 

[Figure  2.5  about  here] 

In  order  to  begin  planning  for  the  development  of  the  training  sub- 
system it  is  necessary  to  make  preliminary  decisions  about  which  tasks 
are  to  be  trained  and  the  means  for  training.  The  ISD  procedure  provides 
guidance  and  criteria  for  the  selection  of  tasks  to  be  trained,  and  similar 
procedures  are  either  available  or  under  development  (e.g.,  STEPS)  for 
identifying  and  specifying  training  device  requirements,  embedded  test 
equipment,  and  embedded  training.  If  training  developers  are  to  impact 
the  early  design  stages  of  system  development  (pre-LOA) , a preliminary 
training  requirement  analysis  is  necessary — even  if  it  must  be  based  on 
rather  sketchy  task  data.  Minimally,  the  outputs  from  this  analysis 
(first  iteration,  pre-LOA)  should  Identify  the  major  training  issues  to 
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Figure  2.5.  Block  4 Training  Requirements  and 
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be  studied  and  resolved  during  the  validation  phase  of  system  developments 
to  allow  specification  of  training  devices,  embedded  training,  and  embedded 
test  equipment  requirements. 

2.6  TRAINING  DEVELOPMENTS  ANALYSIS 

[Figure  2.6  about  here] 

Normally,  the  activities  under  Block  5 are  combined  with  those  In 
Block  6 (Figure  2,7,  Training  Management  and  Planning)  as  an  overall  train- 
ing plan.  They  have  been  separated  here  for  two  reasons: 

a.  Training  development  activities  are  primarily  "technical" 
while  activities  related  to  the  planning  and  management 
for  training  administration  require  organizational  and 
management  skills. 

b.  Implementation  of  a large  scale  training  operation  Is  a 
complex  undertaking  and  should  be  recognized  as  such. 

Training  developments  planning  Is  essentially  the  preparation  of  a 
blueprint  for  the  development  and  acquisition  of  training  materials  and 
associated  documentation.  Also  Included  are  the  technical  means  for  on- 
going assessment  of  training,  and  plans  for  validating  training  materials 
as  they  are  developed  (formative  testing). 

Outputs  from  the  training  developments  analysis  feed  the  total 
system  development  process  In  several  ways: 

a.  Developer  requirements  and  validation  plans  provide 
guidance  for  establishing  contractor  requirements 
and  help  specify  tasks  (e.g.,  training  validation) 
other  than  materials  development  which  are  to  be 
Included  in  the  RFPs  for  validation  and  full-scale 
development. 
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Figure  2.6.  Block  5 Training  Developments  Analysis 
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b.  The  components  of  the  validation  plan  dealing  with 
Army  conducted  Developmental  and,  especially.  Operational 
Testing  feed  into  the  Coordinated  Test  Program. 

c.  ITDT  and  other  training  material  requirements  compose 
the  major  training  input  to  the  RFP  for  contractor  and/ 

I or  in-house  developed  training  materials  and  documenta- 

tion. 

I d.  Training  assessment  planning  provides  inputs  to  SQT  and 

ARTEP  developers  and  to  training  management  planners. 

e.  All  of  the  training  developments  analysis  outputs  are 

of  interest  to  the  developers  of  baseline  cost  estimates 
during  early  stages  of  system  development,  and  will  also 
input  CTEAs  and  COEAs  at  each  stage  of  system  development. 

2.7  TRAINING  MANAGEMENT  AND  PLANNING 

[Figure  2.7  about  here] 

The  primary  activities  in  Block  6 are: 

a.  A "qjiantltatlve"  training  analysis  to  develop  estimates 
of  the  number,  types,  and  distribution  of  individuals 
to  be  trained,  and  of  overall  training  time  require- 
ments. 

b.  A "management"  analysis  to  determine  the  training  support 
requirements,  e.g.,  staffing,  facilities,  supplies  and 
materials,  and  management  or  administrative  require- 
ments at  both  the  institution  and  unit  training  levels. 

c.  Training  planning  to  develop  specifications  for: 

(1)  Establishing  the  training  support  organization. 
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(2)  Executing  the  Implementation  of  training  as  the 
system  goes  through  IOC  and  Is  fielded. 

(3)  Operating  the  training  subsystem  over  the  system 
life  cycle. 

The  outputs  from  these  activities  form  the  Outline  Individual/Collective 
Training  Plan  (OICTP)  during  the  early  stages  of  system  development  and 
provide  training  subsystem  Inputs  to  the  LOA,  Concept  Formulation  Package 
(CFP)  and  Outline  Development  Plan  (ODP) . The  OICTP  is  periodically  updated 
and  becomes  the  ICTP  as  the  system  moves  Into  full-scale  development. 

The  development  of  the  OICTP  requires  extensive  coordination  with 
other  developers.  The  quantitative  training  analysis,  for  example.  Is 
heavily  dependent  on  Information  about  the  composition  of  the  personnel 
subsystem  and  schedules  for  recruitment  and  reassignment  of  personnel  to 
man  the  new  system.  Similarly,  planning  for  extensive  training  In  the  unit 
requires  a commitment  of  resources  to  produce  the  training  capability  In 
the  field  organizations. 
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SECTION  3 


AR  1000-1  and  the  LCSMM  (Army  Pamphlet  11-25)  provide  overall  guid- 
ance for  the  conduct  of  system  development  and  acquisition  activities. 
Activities  within  the  LCSMM  fall  into  four  major  phases:  Conceptual,  Vali- 
dation, Full-Scale  Development,  and  Production  and  Deployment.  This  section 
will  briefly  review  events  and  activities  in  each  phase.  Figure  3.1,  from 
AR  1000-1,  proviaes  an  overview  of  the  materiel  acquisition  process  for 
major  systems.  (See  Appendix  A for  a synopsis  of  AR  1000-1.) 

[Figure  3.1  About  Here] 

3.1  CONCEPTUAL  PHASE 

In  this  phase  the  technical,  military,  logistic,  and  economic 
basis  for  the  program,  and  concept  feasibility  are  established  through 
studies  and  evaluation  of  experimental  hardware  (AR  71-3) . 

3.1.1  Materiel  Concept  Investigation  (Event  1) . TRADOC  conducts 
continuing  analyses  of  mission  areas  to  identify  mission  elements  for 
which  capability  is  deficient.  Identified  needs  are  documented  in  a 
Mission  Element  Needs  Statement  (MENS) , in  terms  of  the  operational  task 
to  be  accomplished.  A Science  and  Technology  Objective  Guide  (STOG)  is 
prepared  describing  an  operational  capability  for  which  technical 
feasibility  has  not  been  proven  and  achievement  is  desired  in  a specified 
time  frame  10  or  more  years  in  the  future. 

3.1.2  Letter  of  Agreement  (LOA)  (Event  2) . The  LOA  is  prepared 
jointly  by  the  Combat  Developer  and  Materiel  Developer  in  accordance 
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Figure  3.1.  Material  Acquisition  Process  for  Major  Systems 
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with  AR  71-9.  The  LOA  outlines  the  basic  agreement  between  developers 
and  identifies  the  studies  needed  to  define  and  develop  system  concepts. 

3.1.3  Special  Task  Force/ Special  Study  Group  (Event  3).  For  major 
systems  establishment  of  STF/SSG  is  part  of  the  LOA  approval  action.  To 
assist  in  selection  of  personnel  TRADOC  has  organized  a Task  Force  Planning 
Group  (TFPG) . STF/SSG  may  validate  the  LOA,  prepare  parts  or  all  of  the 
Concept  Formulation  Package  (CFP)  and/or  decision  documentation  (DCP,  APM, 

DPM). 

3.1.4  Logistic  Support  Planning,  Training  Planning  (Events  4,  4A) . 

Support  systems  planning  proceeds  from  the  results  of  investigations 
identified  in  the  LOA  and  support  subsystem  concepts  prepared  during  and 
following  the  materiel  concept  investigations. 

3.1.5  Organizational  and  Operational  Concepts  (Event  5) . Organiza- 
tional structures  are  reviewed  to  determine  the  impact  of  the  proposed 
system  on  the  force  structure  of  the  Army.  This  activity  precedes  develop- 

( 

ment  of  PQQPRI  and  BOIP  I.  \ 

j 

3.1.6  Baseline  Cost  Estimate  (BCE)  (Event  7) . This  initial  cost  i 

1 

estimate  addresses  both  costs  of  acquisition  and  costs  of  ownership  and  | 

provides  unit  cost  information  to  establish  the  initial  Design  to  Cost  i 

(DTC)  goal.  i 

i 

3.1.7  Concept  Formulation  Package  (CFP)  (Event  8) . The  CFP  i 

evaluates  alternative  system  concepts  (design  alternatives),  and  selects,  • ! 

through  trade-off  analyses  (TOD,  TOA)  the  best  concepts.  A COEA  is 

prepared  documenting  the  analyses  of  the  effectiveness  of  the  selected 

concepts.  I 

i 

3.1.8  Outline  Development  Plan  (ODP)  (Event  9).  The  ODP  is  a plan  j 

for  advanced  development  (AD)  of  system  concepts.  It  is  prepared  prior 
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to  entry  into  the  validation  phase  and,  in  conjunction  with  the  LOA  is 
a document  of  record  to  support  entry  into  AD. 


i 

I 

I 

i 


i 


I 

i 

k 

f 


t 

[ 


3.1.9  Systems  Acquisition  Review  Councils  (Events  12-14).  ASARC  I 
and  DSARC  1 determine  whether  or  not  the  Conceptual  Phase  has  been 
completed  and  determines  if  the  program  is  ready  for  transition  to  the 
Validation  Phase.  An  approved  Decision  Coordinating  Paper  (DCP)  con- 
stitutes a contract  between  OSD  and  the  Army. 

3 . 2  VALIDATION  PHASE 

Validation  activities  resolve  problems  identified  during  the 
Conceptual  Phase,  verify  preliminary  design  and  engineering,  and  prepare 
contracts  as  required  for  full-scale  development.  The  validation  process 
may  be  conducted  by  competitive  or  sole-source  contractors , or  by  in- 
house  development  centers. 

3.2.1  Advanced  Development  Prototype  Contract  (Event  16) . The  ODP 
is  updated,  specifications  for  work  prepared  and  contracts  awarded. 

3.2.2  Inputs  to  DT  I and  OT  I and  Preparation  of  Test  Design 
Plans  (Events  19  and  20).  DT  I and  OT  I are  to  test  the  adequacy  of 
concepts  for  employment,  maintainability,  supportability , organization, 
doctrinal,  tactical  and  training  requirements,  and  related  critical  issues. 
Inputs  to  the  Coordinated  Test  Program  (CTP)  include  test  design  plans 

and  test  support  packages. 

3.2.3  Development  Test  I and  Operational  Test  I (Events  21  and  22) . 
DT  I and  OT  I may  be  conducted  separately  or  coordinated  in  a single  test 
program.  DT  I is  to  demonstrate  technical  feasibility  and  to  ensure  that 
technical  risks  have  been  identified  and  resolved.  OT  I is  conducted  to 
provide  an  indication  of  military  utility  and  worth  to  the  user  and  to 
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provide  data  leading  to  the  decision  to  enter  Full-Scale  Development. 
Results  of  testing,  and  evaluation  reports  are  prepared  and  distributed. 


3.2.4  Update  Subsystem  Plans  (Events  25-30).  Logistics,  personnel, 
training  and  organizational  plans  are  updated  prior  to  entry  into  the 
next  developmental  phase.  Developmental  requirements,  cost  estimates 
and  personnel  requirements  are  revised  and  planning  Initiated.  PQQPRI, 

BO IP-1,  and  TMOS  documents  are  prepared.  ICTP  and  LSA  are  revised. 

Training  Device  Requirements  (TDR)  are  specified. 

3.2.5  Required  Operational  Capability  (ROC)  (Event  31) . The  ROC 
is  prepared.  It  is  a HQDA  document  which  states  concisely  the  minimum 
essential  operational,  technical,  logistical  and  cost  information 
necessary  to  initiate  Full-Scale  development  or  procurement  of  a materiel 
system. 

3.2.6  Special  Task  Force/Special  Study  Group  (Event  32).  Upon 

approval  of  the  ROC  the  determination  will  be  made  for  the  need  of  a 

f i 

STF  or  SSG  (as  described  in  Event  3) . 

3.2.7  Development  Plan  (DP)  (Event  33) . Following  ROC  the  ODP 

► 

► 

i evolves  into  the  DP  for  Full-Scale  Development.  The  DP  constitutes  a 

definitive  plan  for  management  of  the  program  to  accomplish  the 
objectives  addressed  in  the  ROC. 

3.2.8  Systems  Acquisition  Review  Councils  (Events  37-42). 

Validation  IPR,  ASARC  II,  or  DSARC  II,  as  applicable,  are  held  upon 
completion  of  advanced  development  to  assess  the  results  of  the 
Validation  Phase  and  to  ensure  the  system  is  ready  to  proceed  to  Full- 
Scale  development. 
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3.3  FULL-SCALE  DEVELOPMENT  PHASE 


During  this  phase  a system,  including  all  support  items,  is  fully 
developed,  tested  and  initially  type-classified.  Preparations  to  field 
an  integrated  system  are  finalized,  including  BOIP,  personnel  and  equip- 
ment requirements,  publications,  ILS,  and  modifications  of  doctrine, 
organization  and  MOS. 

3.3.1  Engineering  Development  (ED)  Contract  (Event  45).  Materiel 
and  support  requirements  are  prepared  from  the  DP.  RFPs  are  prepared 
and  criteria  established  for  evaluating  contractor  proposals.  Contracts 
are  awarded  and  developmental  activities  monitored. 

3.3.2  Inputs  to  DT  II  and  OT  II  and  Test  Design  Plans  (Events  46-50). 

A coordinated  test  program  is  developed  to  provide  a comprehensive 
evaluation  of  system  components  and  to  ensure  the  system  meets  its  overall 
operational  goals.  Test  support  packages  are  prepared. 

3.3.3  Development  Test  II  and  Operational  Test  II  (Events  51  and  52). 

DT  II  demonstrates  the  technical  capability  of  the  materiel  and  support 
systems,  and  verifies  that  all  design  and  supportability  issues  have  been 
resolved.  OT  II  provides  an  assessment  of  the  system's  military  worth 

and  operational  effectiveness  in  a realistic  operational  environment  by 
using  TOE  units  or  elements  from  normally  assigned  troops.  Test  reports 
and  Independent  evaluation  reports  are  prepared  for  the  decision  process 
leading  to  Full-Scale  production. 

3.3.4  Update  Subsystem  Plans  (Events  57,  57a,  59,  60,  84,  85,  99).  i 

Logistics,  Personnel,  Training  and  Organizational  plans  are  updated.  I 

( 

Draft  TOE,  QQPRI,  MOS,  and  BOIP-II  are  prepared.  As  required,  the  DP  j 

i 

is  updated.  i 
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3.3.5  Development  Acceptance  and  Type  Classification  (Events  69-71). 
ASARC  111  Is  held  to  develop  recommendations  for  entry  Into  full-scale 
or  limited  production.  If  all  critical  Issues  have  been  resolved  the 
system  will  be  type  classified  STANDARD. 

3.4  PRODUCTION  AND  DEPLOYMENT  PHASE 

During  this  phase  support  subsystems  are  established  and  Imple- 
mented, operational  units  are  trained  and  the  materiel  system  Is 
acquired  and  distributed. 

3.4.1  Full-Scale  Production  Contract  (Event  102).  System  production 
contracts  are  awarded.  The  procurement  Includes  support  items  which  must 
be  available  prior  to  release  for  Issue  of  the  materiel  system. 

3.4.2  Army  Authorization  Documents  System  (Event  103).  TOE 
proponents  document  requirements  for  published  TOE  or  TOE  Changes.  Equip- 
ment TAADS  are  established  In  accordance  with  approved  BOIP  11.  CTA 
proponents  document  BOl  upon  type  classification  of  the  system. 

3.4.3  Individual  and  Collective  Training  (Event  104).  Individual 
and  collective  training  begin  following:  final  MOS  decision;  TOE  approval; 
personnel  requirements  determined;  schedule  of  training  Inputs  determined; 
NET  completed;  training  equipment,  aids  and  devices  Issued. 

3.4.4  Initial  Operational  Capability  (IOC)  (Event  105).  IOC  is 
attained  when  the  first  unit  Is  equipped  with  production  Items,  personnel 
are  trained,  and  the  unit  has  the  capability  to  adequately  support  the 
Item  In  the  field. 

3.4.5  Unit  Training  (Event  106) . Unit  training  Is  conducted  in 
accordance  with  Soldier's  Manuals  and  Skill  Qualification  Tests.  Training 
extension  courses,  prepared  by  the  proponent  school,  are  utilized. 
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NET  teams  will  train  a cadre  of  personnel  within  the  unit  who  will  then 
conduct  training. 
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SECTION  4 

TRAINING  ACQUISITION  WITHIN  LCSMM 


4.1  ORGANIZATION 

The  material  in  this  section  is  organized  around  11  LCSMM  events 
listed  in  Figure  4.1. 

[Figure  4.1  about  here] 

Each  of  these  events  consists  of  a set  of  activities  which  culminate  in 
one  or  more  system  products,  e.g..  Letter  of  Agreement,  Outline  Develop- 
ment Plan,  Developmental/Operational  Test  Results.  While  there  are 
many  more  LCSMM  events  than  the  11  we  have  identified  as  "milestone 
events"  (the  LCSMM  describes  119  discrete  events),  most  can  be  subsumed 
under  these  11.  The  objective  here  has  been  to  provide  a manageable 
number  of  LCSMM  events  for  "keying"  training  development  activities, 
without  losing  the  "sense"  of  the  LCSMM  through  excessive  condensation. 
Figures  4.2  through  4.12  depict  major  training  development  and  acquisition 
activities  v ..in  the  LCSMM. 

4.2  SYSTEM  CONCEPTS 

[Figure  4.2  about  here] 

Threat  analyses  and/or  developing  technology  lead  to  consideration  of 
new  system  concepts.  The  rationale  for  new  system  developments  is  a 
defined  capability  deficiency,  l.e.,  a perceived  threat  which  cannot 
sufficiently  be  met  by  existing  (or  planned)  systems.  A Mission  Element 
Needs  Statement  (MENS)  documents  this  deficiency. 

4.2.1  STOG.  The  first  system  development  task  is  to  define  the 
capability  required  to  meet  this  threat  in  terms  of  system  performance 
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objectives.  Science  and  Technology  Objective  Guides  (STOG)  are  developed 
for  specific  scenarios  and  placed  in  a time  frame  when  the  threat  is 
likely  to  materialize.  Development  of  the  STOG  is  the  responsibility  of 
Combat  Developments  (CD)  and  is  part  of  their  ongoing  analysis  activity. 
STOG  provides  the  baseline  from  which  system  and  subsystem  developments 
are  initiated. 

Activities  in  three  areas  are  begun  following  publication  of  a STOG: 

a.  Hardware  or  materiel  system  development 

b.  Support  system  development 

c.  Doctrine  development 

4.2.2  Subsystem  Objectives.  At  a general  level,  objectives  for 
each  subsystem  are  formulated.  Development  of  objectives  is  guided  by 
three  factors: 

a.  Subsystem  "philosophy" 

b.  Subsystem  capabilities 

c.  Subsystem  constraints 

A subsystem  philosophy  is  the  accumulated  body  of  knowledge,  experience, 
and  policy  that  determine  how  subsystem  functions  are  to  be  accomplished 
(e.g.,  "how  to  fight"  manuals).  These  philosophies  provide  an  overall 
theory  or  structure  for  each  activity. 

Subsystem  capabilities  are  existing,  demonstrated,  techniques, 
methods  and  resources.  The  capabilities  are  brought  to  bear  on  the  system 
"problem"  to  provide  solutions  and  contribute  to  system  development. 

Subsystem  constraints  are  the  limitations  and  restrictions  Imposed 
by  a subsystem,  which  must  be  considered  by  other  subsystems. 

It  is  the  responsibility  of  each  subsystem  proponent  to  provide 
state-of-the-art  capabilities  within  his  area  of  expertise.  Identify  the 
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constraints  of  system  development  Imposed  by  the  requirements  of  his 
activity,  and  "adapt"  the  capabilities  of  his  activity  to  the  constraints 
of  others. 
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The  proponent  for  each  subsystem  (and  for  each  component  within  sub- 
systems) prepares  a statement  of  subsystem  objectives  that  is  responsive 
to  the  total  system  STOG.  These  objectives  will,  of  necessity,  be  quite 


general,  but  should  be  as  specific  and  comprehensive  as  possible,  as  they 
form  the  basis  for  generating  system  concepts.  These  objectives  are  "first 
cut"  performance  standards  and  ^ not  deal  with  the  means  by  which  systems 
objectives  are  to  be  met. 

4.2.3  Subsystem  Concepts.  System  concepts  are  generated  through 
analysis  of  capabilities  and  constraints  within  the  philosophy  of  each 
proponent  subsystem.  Often,  a number  of  alternative  concepts  will  be 
developed.  The  key  elements  of  the  concept  formulation  process  are: 

a.  Concepts  should  be  tailored  to  statements  of  objectives. 

b.  Concept  formulation  must  consider  both  capabilities  and 
constraints. 

c.  A justification  for  each  concept  should  be  prepared — 
this  is  a rationale  based  on  the  philosophy  and  policy 
of  the  proponent  organization. 

4.2.4  Integration  of  Concepts.  The  formulation  of  concepts 
normally  should  go  through  several  stages  or  iterations.  "First  draft" 
concepts  should  be  exchanged  among  proponents  for  review.  Minor  or 
major  revisions  may  be  required,  and  it  may  be  necessary  to  review  and 
revise  objectives  at  each  level — up  to  the  STOG — if  major  impact  Issues 
are  identified. 
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Note,  In  Figure  4.2,  that  two  levels  of  Integration  are  Indicated. 


Subsystem  concepts  for  Personnel,  Training,  etc.,  are  to  be  consolidated 
as  "Support  System  Concepts,"  and  Support,  Materiel,  and  Doctrinal 
concepts  are  consolidated  to  form  "Total  System  Concepts." 

4.2.5  Responsibilities.  TRADOC  will  Initiate  subsystem  activities 
by  assigning  concept  development  responsibilities  to  the  various  support 
organizations.  Training  concept  development  will  be  assigned  to  a 
proponent  school,  and  the  school  commandant  will  determine  who,  from  his 
staff,  will  act  as  the  training  representative  for  a specific  system. 

The  designated  training  representative  at  the  assigned  proponent 
school  will  have  the  following  responsibilities: 

a.  Development  of  training  concepts. 

b.  Coordination  of  training  concept  development  with  other 
Interested  schools. 

c.  Coordination  of  training  concept  development  activities 
with  CD,  with  other  support  system  organizations  (Personnel, 

Logistics,  Organization),  and  with  the  Materiel  Developer. 

It  Is  Important  that  the  training  representative  be  provided  with 
the  resc'irces  to  conduct  these  activities,  and  that  he  possess  the 
capability  (training,  experience)  required. 

In  addition,  there  Is  a need  for  a central  point  of  coordination, 
within  TRADOC,  to  oversee  the  Integration  of  the  various  subsystem 
concepts.  This  coordination  role  will  be  assumed  by  the  TSM,  but  must 
be  fulfilled  from  some  other  quarter  until  his  appointment. 

4.2.6  Elements  of  the  Training  Concept.  Generation  of  the  training 
concept  should  Involve  a first  Iteration  of  the  training  developments 
model  to:  develop  a preliminary  task  listing;  Identify  the  kinds  of 
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personnel  required  to  operate  and  ma.lntaln  the  proposed  system;  develop  a 
preliminary  outline  of  training  required;  and  develop  a preliminary  outline 
of  the  training  support  system.  It  Is  Important  to  note  that,  while 
concept  development  activities  will  normally  be  based  on  rather  sketchy 
and  Incomplete  Information  about  the  system.  It  Is  important  that  the 
products  be  as  comprehensive  and  detailed  as  practicable.  There  are 
several  reasons  for  comprehensiveness  and  detailed  development — even  at 
the  risk  of  producing  "low  validity"  products: 

a.  The  concepts  provide  the  basis  for  developing  the  training 
plan  to  be  Included  In  the  LOA.  Well  developed.  If 
tentative,  products  allow  for  better  planning. 

b.  Costing. 

c.  Integration  of  training  with  other  support  subsystems 
can  be  facilitated  by  having  more  specific  Information 
to  work  with  In  examining  the  Interactions  between  sub- 
systems. 

4.3  LETTER  OF  AGREEMENT 

[Figures  4.3  and  4.3a  about  here] 

4.3.1  TSM  Appointment.  At  some  point  In  the  concept  development 
stage,  a decision  will  be  made  to  proceed  to  the  preparation  of  the  LOA. 

It  would  be  appropriate  for  a TSM  office  to  be  established  following  that 
decision,  and  that  the  first  TSM  task  be  the  Integration  of  support 
subsystem  Inputs  to  the  LOA. 

4.3.2  Definition  and  Rationale.  The  LOA  Is  a jointly  prepared 
Combat  Developer  (TRADOC),  Materiel  Developer  (DARCOM)  document  that: 
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a.  Provides  a record  of  the  agreement  between  these  developers 
to  proceed  with  development. 

b.  States  the  Issues  to  be  resolved  through  study  and 
Investigation. 

The  LOA  Is  the  document  of  record  to  support  effort  In  the  system 
advanced  development  category  of  the  RDTE  program.  Systems  with  substantial 
projected  developmental  costs  require  LOA  action  at  HQDA  level. 

The  LOA  Is  a key  document  for  establishing  the  direction  and  scope 
of  the  development  effort.  System  concepts  must  be  sufficiently  developed 
to  allow  Identification  and  definition  of  problems  and  Issues  to  be 
resolved  by  STF/SSG.  Concepts  must  also  be  "operationalized"  to  a degree 
that  allows  reasonable  estimation  of  developmental  costs. 

Areas  that  have  not  undergone  this  preliminary  development  In  the 
concept  stage  are  likely  to  receive  less  than  their  share  of  the  "develop- 
mental pie"  and  their  constraints  cannot  be  adequately  considered  In  the 
early  system  design.  Consequently,  development  of  these  areas  will  lag, 
possibly  resulting  In: 

a.  Failure  to  research  and  resolve  critical  system  Issues 
prior  to  the  tradeoff  determination  and  tradeoff 
analysis  to  select  the  BTA. 

b.  Failure  to  make  provisions  for  needed  work  in  the 
validation  RFF,  and  subsequently,  omission  from  the 
development  contract. 

c.  Difficulty  In  providing  Issues  and  criteria  for  test- 
ing at  DT/OT  I. 
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Impact  on  total  systems  development  Is  likely  to  be  increased 
development  time  as  these  areas  "catch  up"  later,  and/or  decreased 


system  effectiveness  if  these  areas  do  not  meet  their  full  capability 
goals . 

4.3.3  Mission  Crltlcal/Hlgh  Training  Risk  Tasks  Listing.  Figures 
4.3  and  4.3a  show  three  areas  of  activity  culminating  in  training  inputs 
to  the  LOA. 

The  first  activity,  emanating  from  the  Total  Systems  Concepts  is  a 
reiteration  of  the  Front  End  Analysis  resulting  in  a revised  Task  List  and 
from  this  list,  a subset  of  "Mission  Critical/High  Training  Risk  Tasks." 
These  Critical/Risk  Tasks  are  to  receive  full  training  development  during 
the  validation  phase,  will  be  validated  at  DT  I and  demonstrated  or  verified 
in  the  total  system  context  at  OT  I.  The  extent  of  analysis  required  here 
will  be  dependent  upon  the  completeness  of  the  work  done  in  the  concept 
generation  stage  and  the  degree  of  change  and  new  information  available 
following  that  work. 

Close  coordination  with  CD  is  required  to  identify  the  mission 
critical  inputs  to  Critical/Risk  Task  selection.  Behavioral  analysis  will 
be  required  to  input  the  training  risk  component. 

4.3.4  Outline  Individual/Collective  Training  Plan  (OICTP) . The 
second  activity  is  the  development  of  a preliminary  training  plan.  The 
"technical"  part  of  this  plan  is  concerned  with  specifying  the  content 
of  training,  the  modes  for  learning,  and  training  objectives  and  job 
performance  criteria.  Close  coordination  is  required  with  logistics  and 
personnel  developers  to  Incorporate  ITDT  requirements  and  to  ensure 
correspondence  between  personnel  input  capabilities  and  training  and  job 
performance  objectives. 
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The  second  part  of  this  activity  is  the  development  of  a management 
and  administration  plan  describing  how  and  where  training  Is  to  be  done, 
and  Identification  of  the  resources  required  to  support  the  training  effort. 
If  tactical  training  development  occurs  apart  from  the  main  training 
development.  It  should  be  Included  as  a separate  Input.  Note  also  that 
Training  Evaluation  has  been  Included  In  the  OICTP.  This  evaluation 
activity  deals  with  the  ongoing,  internal  evaluation  of  the  training 
process  (e.g.,  ARTEP,  SQT)  and  is  not  to  be  confused  with  the  formative 
evaluation  and  testing  of  training  development  which  becomes  part  of  the 
coordinated  test  programs  for  DT  and  OT. 

4.3.5  Training  Inputs  to  LOA.  The  third  activity  is  the  prepara- 
tion of  Inputs  to  the  LOA.  These  Inputs  Include: 

a.  A description  of  the  proposed  training  subsystem.  Including 
training  developments  required,  and  the  training  management 
and  administration  system. 

b.  A description  of  Issues  and  recommendations  for  studies 
required  to  lead  to  their  resolution. 

c.  An  estimation  of  training  development  costs,  broken  down 
by  major  area.  This  costing  will  also  feed  the  BCE. 

d.  A training  development  schedule. 

4.3.6  Responsibilities.  The  Combat  Developer  (TRADOC)  la  respon- 
sible for  preparation  of  LOA  with  Input  and  coordination  from  the  Materiel 
Developer  and  Logistician.  Assuming  the  prior  existence  of  the  TSM  office, 
the  responsibility  for  this  activity  should  reside  In  that  office. 


4.4  CONCEPT  FORMULATION  PACKAGE 

[Figure  4.4  about  here] 
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4.4.1  Definition.  CFP  can  best  be  characterized  as  a period  of 
study  and  analysis  to  more  fully  determine  the  system  potential  and  to 
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j identify  the  approaches  to  system  development  most  likely  to  optimize  this 

[ potential.  The  CFP  begins  with  approval  of  the  LOA  and  the  establishment 

! of  a STF  and  SSG  and  concludes  with  preparation  of  the  CFP  document  con- 

® talnlng  results  of  the  analyses  to  select  the  best  technical  approach  (BTA) , 

[ and  a COEA. 

4.4.2  Special  Study  Group/Special  Task  Force.  A STF  or  SSG  may  be 
established  as  part  of  the  LOA  approval  process.  Responsibilities  of  the 
STF/SSG  may  be  limited  to  conducting  pre-specif led  investigations  or  may 
be  extensive,  to  Include  further  development  of  the  LOA  and/or  conduct  of 
TOD/TOA/BTA  and  preparation  of  the  CFP. 

Composition  of  a SSG  Is  determined  by  CG  TRADOC.  It  Is  important  that 
qualified  representatives  from  each  activity  be  Identified  and  Included 
on  the  STF/SSG,  and  normally  It  Is  expected  that  the  TSM  be  a member. 

4.4.3  Issue  Investigation.  Issues  relating  to  training  develop- 
ment may  concern  training  development  technology,  capabilities  for  train- 
ing support,  or  special  skill  and  knowledge  requirements.  Special  studies 
may  be  required  to  develop  data  for  costing  training  materials  (e.g. , 

ITDT) , expendables  (e.g.,  training  ammunition)  or  training  devices. 

4.4.4  Best  Technical  Approach.  The  analyses  and  Investigation 
leading  to  the  BTA  determination  are  Intended  to  reduce  the  number  of 
system  and  subsystem  alternatives  for  preliminary  development  to  a 
manageable  level.  The  validity  of  this  process  Is  determined  by  the 
Information  available  at  the  time  these  decisions  must  be  made.  A lack  of 
Information  means  that  decisions,  which  must  be  made,  will  be  arrived  at 
arbitrarily. 
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The  amount  of  effort  required  during  CFP  will  depend  on: 

a.  The  number  of  alternatives  under  consideration. 

b.  The  number  and  extent  of  Issues  to  be  Investigated. 

Costing  and  cost/effectiveness  analysis  are  Intended  to  play  a major 

role  in  the  CFP.  The  BCE  is  revised  and  updated  (COEA) . A CTEA  should  be 
one  element  feeding  the  COEA. 

4.4.5  Responsibilities . Responsibility  for  preparing  the  CFP  and  i 

the  activities  leading  to  this  document  will  vary  according  to  the  re-  | 

I 

sponsiblllties  assigned  to  STF/SSG.  A TSM  would  normally  be  a member  of  j 

a STF  or  SSG,  and  possibly  should  chair  a SSG.  The  TSM  should  participate  I 

In  Identifying  members  of  a STF/SSG  to  ensure  appropriate  support  sub- 
systems representation. 

J 

I 

] 

4.5  OUTLINE  DEVELOPMENT  PLAN  J 

[Figure  4.5  about  here]  j 

4.5.1  Definition.  ODP  is  the  planning  activity  following  selection  j 

of  BTA  to  be  pursued  in  validation  development.  ODP  results  In  a planning  | 

document  which  provides  the  requirements  for  development  activity.  j 

I 

The  analyses  carried  out  during  CFP  should  provide  new  detailed  ' 

j 

Information  for  those  systems  and  subsystem  alternatives  selected  for  j 

validation  development.  Planning  for  training  development  is  shown  as  j 

t 

occurring  In  three  areas:  j 

a.  Updating  training  development  requirements.  ' 

b.  Updating  the  Outline  Individual/Collective  Training  Plan.  | 

c.  Preparing  the  Training  Testing  Plan.  I 


J 
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4.5.2  Training  Development  Requirements.  The  primary  emphasis  for 
training  development  during  the  Validation  Phase  will  be  to  determine 
that  It  Is  feasible  to  provide  training  for  high-risk  tasks.  The  ODP  will 
list  known  high-risk  tasks  and  Identify  requirements  for  validating  this 
listing  and  modifying  It  as  appropriate.  Requirements  will  be  Included 
for  development  of  training  materials  and  training  devices  to  demonstrate 
training  on  these  tasks.  Long  lead  time  Items  will  also  be  addressed 

as  will  Items  that  will  be  "locked"  Into  the  design  at  an  early  stage 
(e.g.,  embedded  training,  embedded  test  equipment). 

4.5.3  Update  OICTP.  New  data  related  to  training  management  and 
administration  will  be  Incorporated  Into  the  OICTP,  which  Is  Included 
In  Section  V of  the  ODP. 

4.5.4  Training  Test  Plan.  Trainers  are  required  to  develop 
Issues  and  criteria  for  testing  and  evaluation  at  DT/OT  I.  These  may 
concern  training  technology  and/or  training  support.  In  addition, 
the  training  test  plan  should  consider  contractor  and  In-house 
testing  and  validation  of  training  development  prior  to  the  conduct 
of  DT/OT  I.  The  Training  Test  Plan  becomes  part  of  Section  IV 
(Coordinated  Test  Program)  of  the  ODP. 

4.5.5  Responsibilities.  The  TSM  should  monitor  the  updating  of 
training  development  requirements  and  the  OICTP.  These  actlvltes  would 
be  carried  out  by  the  proponent  school.  The  TSM  would  coordinate  these 
activities  with,  primarily,  logistics  and  personnel  organizations  to 
ensure  correspondence  between  task  requirements  and  training,  and 
personnel  capabilities  and  training.  Close  coordination  with  training 
device  developers  will  also  be  required. 
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A representative  from  the  TSM  office  should  be  included  in  the 


r 

I JWG  for  testing. 

I 

; 4.6  RFP,  VALIDATION 

! [Figure  4.6  about  here] 

4.6.1  Definition.  RFP  Vali  atlon  includes  the  activities  required 

I 

[ to  prepare  specifications  for  the  RFP,  evaluate  proposals  and  select 

I contractors,  and  to  monitor  contractor  work  to  provide  the  products  for 

I DT/OT  I. 

4.6.2  Specifications  for  Training  Development  and  Validation. 
Specifications  for  training  development  are  derived  from  the  requirements 
described  in  the  ODP,  and  describe  the  work  to  be  accomplished  by  the 
developmental  contractors. 

Training  developments  are  to  occur  on  two  levels  during  the 
validation  phase: 

a.  Training  materials  and  ITDT  are  to  be  provided  at 
DT/OT  I for  high-risk  tasks. 

I b.  Analyses  and  training  requirements  for  other  (low 

risk)  tasks  will  proceed  sufficiently  to  provide 

[ operator /maintainer  capabilities  for  DT/OT  I. 

I 

Also,  long  lead  time,  expensive  components  (e.g.,  simulators)  are  to 
be  developed  and  provided  (in  at  least  "breadboard"  form)  for  DT/0''f’  I,  as 
are  embedded  test  equipment  and  embedded  training. 

A key  to  the  scope  of  work  required  during  validation  development  is 
the  accuracy  of  the  high-risk  task  list  provided  in  the  specifications. 
Provisions  must  be  made  for  revision  of  this  list  early  in  the  contract 
stage  as  the  contractor  FEA  proceeds. 
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Figure  4.6.  RFP,  Validation 


The  role  of  DT/OT  I is  primarily  to  ensure  that  developmental 
products  have  achieved  their  stated  goals.  The  "increased  emphasis  on 
testing"  indicates  that  provisions  be  built  into  the  developmental  cycle 
to  ensure  thorough  validation  of  individual  products  prior  to  their 
submission  for  overall  system  operational  testing.  There  are  well 
established  procedures  and  facilities  (i.e.,  proving  grounds,  labs)  for 
DT  of  hardware  components.  Apparently  the  same  capability  does  not  exist 
for  testing  and  evaluating  other  subsystems.  Therefore,  procedures  should 
be  developed  and  resources  Identified  as  part  of  the  developmental  effort. 
Test  and  validation  requirements  that  are  to  be  met  by  the  contractor 
should  be  made  part  of  the  trainer  input  to  the  RFP. 

A. 6.3  Specifications  for  Training  Support.  Specifications  for 
development  of  the  OICTP  should  be  prepared.  Although  this  is  mainly  an 
in-house  activity,  the  OICTP  is  a "product"  to  be  evaluated  at  DT/OT  I 
and  the  specifications  for  its  development  will  enable  the  parties 
responsible  for  ensuring  its  development  to  monitor  its  progress  during 
development. 

4.6.4  Proposal  Evaluation/Contractor  Selection.  Training  (and 
other  support  subsystem)  developers  should  play  an  active  role  in  the 
evaluation  of  proposals  and  should  make  recommendations  for  contractor 
selection  based  on  the  quality  of  the  proposal  and  qualifications  of 
contractor  personnel  to  perform  the  FEA  and  training  developments. 

Criteria  for  proposal  evaluation  should  be  prepared. 

4.6.5  Monitor  Developmental  Efforts.  Following  contract  award, 
close  coordination  with  the  contractor  will  be  required  to: 

a.  Ensure  the  contractor  is  Included  in  the  flow  of 
Information. 
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I b.  Monitor  progress  of  developmental  activites. 

t 

I c.  Participate  in  validation  and  verification  of  products. 

I 

t Although  overall  contract  responsibilities  reside  with  the  materiel 

I developer,  it  should  be  a TSM  function  to  provide  quality  assurance 

I monitoring  for  training  developments,  and  he  should  have  a least  joint 

"sign-off"  authority  over  training  development  products. 

I 

14.6.6  Responsibilities.  The  materiel  developer  has  overall 

responsibility  for  preparation  of  the  RFP,  contract  award  and  monitoring 
of  developmental  contracts. 

The  TSM  should  be  responsible  for  and  have  joint  sign-off  authority 
for  training  developments  and  other  support  subsystem  inputs  to  the  RFP. 

I Preparation  of  specifications  should  be  done  by  the  proponent  organiza- 

I tions  (e.g.,  proponent  school).  The  TSM  should  review  specifications  to 

r 

I ensure  their  completeness  before  submitting  them  to  the  materiel  developer. 

V 

Specifications  for  FEA  and  ITDT  must  be  coordinated  with  the  logistics 
proponent,  training  device  specifications  coordinated  with  the  training 
device  developer,  and  specifications  for  embedded  training  and  test  equip- 
ment coordinated  with  the  materiel  developer. 

The  TSM  should  have  responsibility  for  developing  "in-house" 
specifications  for  the  OICTP  and  for  validation  and  verification  of 
developmental  products. 

As  discussed  above,  the  TSM  should  establish,  through  the  materiel 
developer,  a liaison  relationship  with  the  training  development  con- 
tractor. 

4.7  TESTING,  DTI  AND  OTI 

[Figure  4.7  about  here] 
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4.7.1  Definition.  Development  and  Operational  Testing  during  the 
validation  are  intended  to  prove  the  feasibility  of  the  system  concepts 
and,  frequently,  to  narrow  the  choice  of  alternative  concepts  through 
competitive  testing.  Testing  is  also  used  to  generate  data  for  costing 
purposes.  For  Training,  DT/OT  I is  intended  to  demonstrate  that  high-risk 
tasks  can  be  trained  satisfactorily,  that  expensive  and/pr  long  lead- 
time  training  items  can  be  provided,  and  that  a feasible  training  support 
system  can  be  developed. 

4.7.2  DT  I,  Training.  DT  tests  to  ensure  that  subsystem  products 
meet  specifications  established  for  that  subsystem,  e.g.,  that  training 
provides  the  skills  and  knowledge  as  specified  in  the  training  objectives. 

A test  plan  must  contain  objectives  for  testing  that  are  stated  in  a 
manner  that  will  facilitate  their  measurement.  The  tester  and  proponent 
organization  must  work  out  the  measures  to  be  used  and  the  details  and 
conditions  of  the  test  setting. 

For  developmental  testing,  decisions  must  be  made  about  where  testing 
is  to  be  done  and  what  subsystems  are  to  be  tested  together  or  concurrently. 
It  is  envisioned  that  much  of  the  DT  level  testing  for  training  will  be 
conducted  by  the  contractor. 

To  ensure  that  materials  are  ready  for  operational  testing,  the 
operational  tester  may  require  the  proponent  of  each  subsystem  to  submit 
an  Operational  Testing  Readiness  Statement  (OTRS)  as  a verification  that 
DT  objectives  have  been  met. 

4.7.3  OT  I,  Training.  OT  I should  evaluate  the  feasibility  of  the 
"training  concept"  as  it  is  described  in  ti.e  OICTP.  OT  I should  also 
Include  studies  to  ensure  that  training  objectives,  to  which  training 
materials  are  geared,  are  valid,  l.e.,  that  Individuals  trained  to  the 
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objectives  can  perform  at  a level  consistent  with  system  needs.  Other 
or  I training  concerns  may  Include;  studies  to  generate  data  for  CTEA/COEA 
and  evaluation  of  plans  for  continued  training  development. 

4.7.4  Responsibilities . The  Materiel  Developer  and  Operational 
Tester,  respectively,  are  responsible  for  the  conduct  of  DT  and  OT.  The 
proponent  for  each  subsystem  is  responsible  for  making  Inputs  to  the 
Coordinated  Test  Program  for  their  area  (Criteria  and  Issues  for  Testing). 
As  support  subsystem  testing  has  not  been  emphasized  in  the  past,  and  the 
capability  for  testing  is  not  well  developed,  subsystem  proponents  should 
take  an  active  role  in  the  development  of  criterion  measures  and  the  design 
of  test  settings.  For  training,  and  other  support  subsystems,  the  TSM 
shsHild  be  responsible  for  ensuring  that  issues  and  criteria  for  testing 
are  developed  and  supplied  to  the  appropriate  tester,  and  should  ensure 
that  test  situations  include  support  subsystem  components. 

TSM  should  also  monitor  development  activities  (both  contractor  and 
in-house)  to  ensure  that  validation  and  verification  testing  occurs  as 
required.  The  TSM  should  also  be  responsible  for  obtaining  the  signoff 
on  the  OTRS  for  training  prior  to  Operational  Testing. 

4.8  REQUIRED  OPERATIONAL  CAPABILITY 

[Figure  4.8  about  here] 

4.8.1  Definition.  Analysis  of  the  results  of  testing  leads  to  a 
recommendation  for  the  development  of  one  system  from  the  alternatives 
tested  at  DT/OT  I.  The  ROC  activity  updates  system  operational  criteria, 
describes  the  system  that  will  meet  these  criteria,  describes  the  work 
required  to  develop  that  system,  and  updates  acquisition  and  life  cycle 
cost  estimates. 
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Movement  from  the  Validation  Phase  to  the  Full-Scale  Development 


Phase  implies  that  major  issues  have  been  resolved  and  the  concept 
validated.  The  updating  of  operational  criteria  should  be  mainly  a 
refinement  of  existing  criteria. 

4.8.2  Update  Training  Requirements.  Refinement  of  System 
Operational  Criteria  may  cause  modification  to  human  performance  require- 
ments and  training  requirements.  Changes  to  system  criteria  should  be 
carefully  reviewed  by  training  developers  to  ensure  that  job  performance 
and  training  requirements  are  in  full  agreement  with  these  higher  level 
criteria. 

4.8.3  Additional  Training  Developments.  Training  development  will 
refocus  from  high-risk  tasks  to  the  development  of  the  total  training 
subsystem.  This  will  require  development  of  low-risk  task  training 
materials,  and  integration  of  high-risk  training  materials  into  a total 
training  package.  Tactical  training  should  also  be  merged  into  this  pack- 
age. TDRs  for  System  and/or  Non-System  Devices  are  prepared  and,  if  approp- 
riate, a separate  ROC  for  these  devices  developed. 

4.8.4  Update  OICTP.  The  OICTP  must  be  refined  and  expanded  with 
more  detail  generated  during  validation  development  and  testing.  Training 
development  cost  estimates  are  updated  and  life  cycle  training  cost 
estimates  generated.  While  the  ROC  document  is  succinct  and  brief,  it 
requires  extensive  supporting  documentation. 

4.8.5  Responsibilities.  The  main  purpose  of  the  ROC  is  to  provide 
the  information  required  to  determine  the  potential  of  a system  in  terms 
of  operational  capability  and  the  cost  of  this  capability.  It  is  the 

responsibility  of  each  subsystem  proponent  to  develop  the  data  for  his 

I 

i area  that  will  allow  reasonable  judgments  to  be  made  on  these  parameters. 

i 

I 


i 

1 
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TSM  responsibilities  should  Incliule: 

a.  Ensure  performance  standards  and  training  objectives 
are  updated. 

b.  Ensure  OICTP  updated  and  In  sufficient  detail  to  allow 
reasonable  life  cycle  costing. 

c.  Ensure  these  data  are  provided  to  organizations  respon- 
sible for  preparing  cost  estimates. 


4.9  DEVELOPMENT  PLAN 

[Figure  4.9  about  here] 

4.9.1  Def inltion.  Following  ROC  approval  the  ODP  is  updated  and 
becomes  the  Development  Plan  (DP).  A STF/SSG  may  be  established  (or 
reconvened)  to  resolve  any  remaining  system  Issues.  The  DP  is  to 
include  full  specifications  for  the  remaining  system  development, 
including  all  items  of  support. 

4.9.2  Training  Plan  Development.  A plan  will  be  prepared  for  the 
development  and  acquisition  of  all  training  materials,  training  devices 
and  training  aids  required  for  institution  and  unit  training.  This  plan 
will  also  provide  for  the  development  of  all  supporting  documentation 
not  included  in  ITDT. 

The  OICTP  will  be  updated  to  become  the  ICTP.  It  will  describe  full 
plans  for  individual  and  collective  training  at  both  institution  and  unit 
levels.  A training  "start-up"  and  implementation  plan  will  be  developed 
to  phase  in  the  training  for  the  new  system.  NET  will  be  a key  element 
of  this  plan.  NET  will  be  the  primary  means,  for  most  systems,  for 
establishing  the  training  capability  at  the  unit  training  level. 
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4.9.3  Training  Test  Plan.  The  test  plan  will  cover  contractor  and 

government  testing  and  validation  of  training  materials,  evaluation  of  the  , 

training  Implementation  plan,  and  training  support  for  DT/OT  II  testing.  | 

4.9.4  Responsibilities . The  TSM  should  be  responsible  for  ensuring  i 

that  all  remaining  training  development  requirements  are  Included  In  the  j 

DP.  He  should  also  review  and  approve  the  ICTP  prior  to  submission  for 

Inclusion  In  the  DP.  At  this  time  personnel  and  organizational  develop- 

i 

1 

ments  are  also  being  finalized.  The  TSM  office  should  coordinate  with 

j 

these  activities  to  ensure  the  training  subsystem  Is  In  concurrence  ; 

J 

with  QQPRI,  BOIP,  and  TOE.  ^ 

i 

4.10  RFP,  FULL-SCALE  DEVELOPMENT 

[Figure  4.10  about  here]  j 

4.10.1  Definition.  Activities  In  RFP,  Full-Scale  Development  j 

essentially  parallel  those  described  In  paragraph  4.6.  Specifications 

for  contractor  and  In-house  development  are  prepared,  contracts  let  and 
development  activities  monitored. 

I 

4.10.2  Specifications  for  Training  Development  and  Training  Support. 

Specifications  are  prepared  for  developing  all  remaining  training  materials  j 

and  devices.  In-house  specifications  are  prepared  for  developing  the 

training  support  organization.  Including  facilities,  and  training  and  | 

I 

training  support  personnel.  Specifications  are  developed  for  activities  j 

to  establish  and  schedule  NET  to  ensure  the  field  training  capability  Is 
Installed  prior  to  IOC. 

4.10.3  Responsibilities . The  TSM  should  review  all  proposed  train- 
ing development  Inputs  to  the  RFP  to  ensure  speclfcatlons  cover  all 
required  developmental  activities.  TSM  should  supply  criteria  for 
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Figure  4.10.  RFP,  Full-Scale  Development 


proposal  evaluation  and  ensure  that  training  development  interests  are 
represented  in  proposal  review  and  contractor  selection.  TSM  should 
provide  liaison  between  the  training  proponent  and  the  contractor,  and 
should  be  involved  in  contractor/government  tests  and  validation  activities 
for  training  materials. 

The  TSM  office  should  also  coordinate  the  development  of  the  ICTP 
within  TRADOC  and  with  other  developers.  During  this  period  the  TSM 
should  closely  monitor  all  system  development  activities  to  ensure 
training  and  other  support  subsystem  activities  are  within  their 
scheduled  development  time  lines,  and  to  ensure  that  system  changes  are 
reflected  in  support  subsystem  activities. 

4.11  TESTING,  DT  II  AND  OT  II 

[Figure  4.11  about  here] 

4.11.1  Definition.  DT  II  and  OT  II  are  now  intended  to  demonstrate 
that  all  system  issues  have  been  resolved,  and  that  the  system  can  be 
operated  and  maintained  in  the  field.  For  OT  II,  it  is  required  that 
support  subsystems  be  available  for  testing. 

4.11.2  DT  II,  Training.  Contractor  and  Government  Testing  of  all 
training  materials  will  be  conducted  to  demonstrate  their  validity  in 
meeting  training  objectives.  ITDT  materials  will  be  extensively 
validated  using  typical  user  personnel  in  sufficient  numbers  and  under 
appropriate  test  conditions  to  ensure  reliable  test  results.  The 
training  capability  will  be  sufficiently  established  at  DT  II  to  allow 
testing  of  the  training  process,  including  instructional  systems,  train- 
ing devices,  and  documentation,  and  NET.  As  feasible,  the  "exercising" 
of  this  capability  will  provide  trained  player  personnel  for  OT  II. 


( 

t 
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4.11.3  OT  II,  Training.  OT  II  will  evaluate  the  capability  of  the 


1 

■I 

i 

i 

I 

\ 

i 


total  training  package  to  provide  the  required  training,  (validation  of 
training  objectives),  and  assess  the  feasibility  of  implementing  the 
proposed  ICTP. 

4.11.4  Responsibilities . Full-scale  testing  and  validation  of  the 
training  subsystem  prior  to  and  during  DT/OT  II  will  be  extensive.  The 
TSM  office  should  be  responsible  for  monitoring  development  activities  to 
ensure  that  both  training  materials  and  the  required  elements  of  the 
training  process  are  available  for  testing  at  designated  milestones.  The 
TSM  should  also  coordinate  test  preparation  activities  with  the  contractor 
and  the  operational  tester  to  ensure  appropriate  materials,  test  condi- 
tions, and  personnel  are  available. 

Where  OT  II  testing  calls  for  training  support  using  elements  of 
the  proposed  training  process,  the  TSM  must  ensure  that  these  elements 
are  developed  and  tested  well  in  advance  of  OT  II. 

4.12  INITIAL  OPERATIONAL  CAPABILITY 

[Figure  4.12  about  here] 

4.12.1  Definition.  IOC  is  attained  when  the  first  MTOE  troop  unit 
has  been  trained  to  use  and  employ  the  system  and  the  unit  has  the 
capability  to  support  the  use  of  the  system  in  the  field. 

4.12.2  Establish  Training  Facilities.  Personnel  Support.  The 
training  subsystem  is  to  be  tested  and  validated  at  DT/OT  II.  Assuming 
that  this  is  accomplished,  the  period  following  DT/OT  II  through  IOC  is 
' b«  uaad  to  establish  a training  capability  through  implementation  of 

>>•  ' ’T?  Training  subsystem  activities  will  include; 

4.  Modifying  and  establishing  training  facilities. 
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b.  Acquiring  and  preparing  training  and  training  support 
staffs. 

c.  Producing  and  distributing  training  materials  and  train- 
ing support  materials. 

Training  implementation  will  be  interdependent  with  other  personnel 
and  organizational  actions  required  to  recruit  and  supply  personnel  to  be 
trained  and  assigned  to  the  new  system. 

The  introduction  and  extensive  use  of  ITDT,  which  should  even- 
tually result  in  a reduced  overall  training  requirement,  will  initially 
require  a heavy  investment.  A distribution  system  must  be  established 
to  ensure  availability  of  and  access  to  materials  on  a timely  basis. 
Provisions  must  be  made  at  the  unit  level  to  ensure  training  time  is 
available  and  controls  established  to  ensure  materials  are  used.  The 
NET  program  will  be  utilized  to  provide  this  capability. 

Large  scale  programs  will  require  a gradual  "phase  out — phase  in" 
implementation  plan  to  establish  the  new  system.  This  process  must  be 
carefully  coordinated  with  personnel  and  organizational  actions  to 
recruit  and  reassign  personnel  to  the  incoming  system. . 

4.12.3  Initiate  Training.  The  training  support  organization  must 
be  in  existence  before  training  can  begin.  Where  systems  will  be  manned 
both  by  transfer  personnel  from  similar  jobs  and  by  new  recruits, 
separate  training  programs  will  be  required.  During  initial  "phase  in" 
training  a troubleshooting  capability  should  be  available  to  handle 
start-up  problems. 

4.12.4  Training  Evaluation.  SQT  and  ARTEP  are  to  be  established 
with  new  training  programs.  This  capability  should  be  an  integral  part 
of  the  total  implementation  program. 
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4.12.5  Responsibilities.  During  the  early  Implementation  stage. 


the  TSM  should  be  responsible  for  tracking  the  acquisition  of  facilities 
and  materials,  and  should  act  as  coordinator  between  NET  and  the  user 
organizations  for  the  development  of  the  training  and  support  staff. 

The  TSM  should  also  track  personnel  and  organizational  actions  that 
are  to  provide  operator  and  maintenance  personnel  to  the  new  system.  As 
the  system  Is  Introduced,  the  TSM  should  ensure  the  Introduction  of  the 
Training  Evaluation  Activity. 
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SYNOPSIS  (FOR  TRAINING)  OF  AR  1000-1 
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CHAPTER  1 
GENERAL 


1.1  Purpose.  This  regulation  establishes  basic  Army  Policy  for  acquisition 
of  materiel  systems  and,  together  with  AR  15-14,  implements 
DOD  Directives  5000.1  and  5000.2. 


1 1.2  Applicability  and  Scope. 

I a.  The  general  principles  of  this  regulation  apply  to  the  development 

and  acquisition  of  all  Army  materiel  systems The  term  "materiel 

1 system"  refers  to  a major  end  item,  all  components,  subsystems,  and  ord- 

i nance  essential  to  its  operational  employment,  plus  its  complete  system 

: support  package. 

f b.  This  regulation  describes  the  system  acquisition  process  in  detail 

E for  major  systems  from  Initiation  (identification  of  a mission  need)  through 

I successful  completion  of  development,  production,  and  deployment. 

f 

I 

I 
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CHAPTER  2 


MATERIEL  ACQUISITION  POLICY 


2.1  Decision-Making  Levels 

a.  (1)  Materiel  programs  involving  anticipated  cost  of  $75  million 
in  RTDE  or  $300  million  in  procurement  appropriations  will  be  considered 
for  designation  as  major  system  acquisition  programs. 

(3)  The  Mission  Element  Need  Statement  (MENS)  will  be  used  to  < 

describe  the  mission  and  to  justify  the  Initiation  of  a new  major  system  j 

acquisition  (see  AR  71-9). 

2.3  Technology  Base  | 

a.  Long-range  research  objectives  will  be  defined  by  science  and  | 

technology  objectives  (STO).  A compendium  of  STO  will  be  published  in  the  \ 

Science  and  Technology  Objectives  Guide  (STOG).  STO  will  be  formulated  I 

by  the  user  representative  (usually  TRADOC)  and  will  be  processed  in  a 

manner  similar  to  that  for  ROC.  | 

1 

2.4  Project  Management 

a.  After  approval  of  the  MENS  at  Milestone  0,  a Special  Task  Force  j 

(STF)  or  Special  Study  Group  (SSG)  will  be  formed  to  conduct  the  explora- 
tion of  alternative  system  concepts.  The  director  of  the  STF  or  SSG  will  j 

manage  the  program  between  Milestone  0 and  I.  j 

b.  When  a system(s)  has  been  identified,  at  Milestone  I,  for  demon- 
stration and  validation,  a project  manager  (PM)  will  be  assigned  for  all 
major  systems. 

j . The  PM  will  ensure  that  ILS  requirements  are  taken  into  account 
at  all  stages  of  system  development  and  that  system  support  planning  i 

proceeds  in  phase  with  system  development  and  procurement.  j 

i 

l.  The  PM  will  participate,  as  necessary,  with  the  development  tester,  | 

operational  tester,  combat  developer,  logistician,  and  other  materiel  devel- 
opment agencies  in  all  aspects  of  testing.  | 

m.  The  PM  will  participate  with  TRADOC  in  developing  costing,  schedul-  ] 

Ing,  and  logistical  data  as  required  to  support  cost  and  operational  effec- 
tiveness analyses  (COEA) . j 

2.5  TRADOC  Systems  Management  | 

a.  For  major  systems  and  selected  non-major  systems,  a TRADOC  Systems 
Manager  (TSM)  will  be  appointed  by  CDR,  TRADOC  following  program  initiation 
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(Milestone  0) . This  will  provide  for  the  coordinated  development  and 
integration  of  user  requirements  as  well  as  system  support  packages 
from  the  onset  of  program  evaluation. 

(1)  The  TSM  will  ensure  that  user  requirements  are  taken  into 
account  early  and  continuously  thereafter.  . . . 

(2)  Following  program  approval,  the  TSM  will  coordinate  re- 
validation  of  the  requirements,  as  needed.  . . . 

(3)  The  TSM  is  responsible  for  coordinating  the  combat  developer, 
user,  and  trainer  efforts  in  the  life  cycle  management  of  the  assigned 
system. 

(4)  The  TSM  is  responsible  for  doctrinal  and  organizational 
standardization  or  Interoperability  with  NATO  allies. 

2.6  Time  to  Complete  Development 

a.  Materiel  systems  will  be  acquired  within  the  shortest  reasonable 

time. 

b.  The  goal  is  to  achieve  IOC  within  5 years  after  FSED  approval 

and  to  do  so  within  established  cost  goals  and  without  incurring  inordinate 
risks.  However,  successful  achievement  of  program  objectives  rather  than 
calendar-controlled  milestones  will  be  the  primary  factor.  To  justify 
scheduling  a decision  milestone,  adequate  progress,  generally  confirmed 
by  testing  and  including  examination  of  the  training  and  logistic  support- 
ability  must  be  demonstrated.  . . . Although  decision  milestones  must 
be  event-oriented,  acquisition  strategy  must  consider  also  the  timing  of 
planning,  programming,  and  budgeting  system  (PPBS)  cycle,  and  must  be 
accommodated  to  that  cycle. 

2.7  Program  Stability.  All  agencies  associated  with  a program  .... 
must  resist  attempts  to  change  a program  which  is  achieving  established 

goals. 

2.10  Threat  Assessment 

a.  Consideration  of  threat  and  its  implications  for  materiel  develop- 
ment must  be  continuous  throughout  the  life  cycle  of  Army  systems.  To  pro- 
vide time  for  necessary  research  and  analysis,  early  identification  of 
requirements  for  threat  evaluation  is  of  particular  importance. 

b.  At  each  milestone  in  the  materiel  acquisition  decision  process, 
review  of  the  threat  assessment  is  essential.  . . . 

2.11  Technical  Risk 

a.  High  risk  programs  carry  greater  cost  and  schedule  risk  and 
should  be  avoided  .... 


2.13  Integrated  Logistic  Support  (ILS) 


a.  . . . Concurrently,  the  Army  must  develop,  acquire,  test,  and 
deploy  the  required  support  resources  as  an  integral  part  of  the  materiel 
acquisition  process.  Such  resources,  collectively  referred  to  as  system 
support.  Include  support  and  test  equipment,  skilled  personnel  (including 
the  training  programs  and  training  devices  needed  to  develop  those  skills) , 
supply  support,  technical  logistic  data,  and  facilities.  ILS  is  the  process 
through  which  these  requirements  are  achieved  (see  AR  700-127). 

b.  (3)  Alternative  support  concepts  will  be  considered  during  the 
exploration  of  alternative  system  concepts  to  Identify  impact  on  system 
design  and  support  resources. 

(4)  The  number  and  skill  levels  of  personnel  required  and  human 
engineering  factors  will  be  included  as  constraints  in  system  design. 

(5)  System  support  planning  actions  will  be  addressed  in  the 
Letter  of  Agreement  and  in  the  Outline  Acquisition  Plan.  Detailed  support 
planning  will  begin  during  the  demonstration  and  validation  phase  and  firm 
support  requirements  will  be  established  early  in  the  FSED  phase. 

(6)  A preliminary  system  support  package  will  be  evaluated  during 
OT  I;  a complete  system  support  package  will  be  validated  before  Milestone 
III. 

c.  Materiel  systems  developed  or  acquired  by  the  Army  must  be 
supportable  by  the  personnel  skills  available.  Timely  training  support 
must  be  provided  in  order  to  sustain  operational  effectiveness  for  the 
life  cycle  of  the  system/item.  The  development  of  materiel  and  support 
planning  will  consider  the  growing  number  of  women  in  the  Army.  Integra- 
tion of  the  human  element  and  system  will  start  with  initial  concept 
studies,  be  progressively  refined  as  the  system  progresses,  and  be  docu- 
mented in  the  logistic  support  analysis  (LSA) . LSA  documentation  will 
form  the  basis  for  personnel  authorization  criteria,  personnel  selection 
and  training,  development  of  training  devices  and  simulators,  and  planning 
related  to  human  factors.  Human  factors  considerations  will  be  validated 
during  DT/OT  as  part  of  the  system  support  package. 

2.17  Test  and  Evaluation 

a.  Test  and  evaluation  will  begin  as  early  as  feasible  in  the  acqui- 
sition cycle  and  will  be  conducted  throughout  the  system  acquisition 
process  as  necessary  to  assess  acquisition  risks,  to  evaluate  operational 
effectiveness  and  suitability,  to  evaluate  logistic  supportablllty,  and 

to  determine  interoperability  with  NATO  systems.  . . . When  feasible  and 
practical,  the  tests  should  be  conducted  with  representative  prototypes 
in  realistic  operating  environments. 

b.  ...  if  test  results  reflect  significant  deficiencies.  Including 
deficiencies  in  the  system  support  package,  the  program  will  not  move  into 
a succeeding  phase  until  all  significant  deficiencies  have  been  corrected 
and  corrections  verified  by  retest.  A deficiency  will  be  considered 


significant  If  It  would  make  the  system  unacceptable  for  deployment  or  If 
correction  involves  more  than  the  most  routine  engineering. 
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c.  Development  test  and  evaluation  (DT&E)  is  conducted  to  assist 

ithe  engineering  design  and  development  process  and  to  verify  attainment  of 
technical  performance  specifications  and  objectives  . . . using  experi- 
I enced  and  qualified  civilian  and  military  personnel. 

d.  Operational  test  and  evaluation  (OTSE)  is  conducted  to  estimate 
; a system's  operational  effectiveness  (including  vulnerability)  and  opera- 

^ tional  suitability  (including  compatibility,  interoperability,  reliability, 

> availability,  maintainability  (RAM),  logistic  supportability , safety, 

I health,  human  factors,  and  tralnabillty) , as  well  as  the  need  for  any 

I modifications.  In  addition,  OT&E  provides  information  on  organization, 

\ personnel  requirements,  doctrine,  and  tactics.  OT&E  will  be  accomplished 

( by  TOE  units  using  operational  and  support  personnel  of  the  type  and 

t qualifications  of  those  expected  to  use  and  maintain  the  system  when 

I deployed.  It  will  be  conducted  in  as  realistic  an  operational  environment 

I,  as  possible. 

i 

e.  Force  development  test  and  experimentation  (FDTE)  supports  the 
materiel  acquisition  process  by  providing  essential  information  at  key 
decision  reviews.  FDTE  may  be  used  to  develop  the  concept  of  employment, 
determine  operational  feasibility,  estimate  the  potential  operational 
[ advantage  of  a proposed  system,  and  assist  the  combat  and  materiel  developers 

[ in  the  development  of  Letters  of  Agreement  (LOA) . 

g.  Sufficient  test  hardware  and  elements  of  the  system  support  package 
will  be  procured  early  enough  to  prepare  for  validation  during  DT/OT  II. 
Detailed  planning  will  be  initiated  during  the  demonstration  and  validation 
phase  so  that  preliminary  logistics,  personnel,  and  training  support  packages 
may  be  evaluated  during  DT/OT  I and  firm  requirements  can  be  established 
early  in  the  FSED  phase. 

1.  In  order  to  be  prepared  to  carry  out  their  responsibilities  in 
parallel  with  those  of  the  developer  during  the  FSED  phase,  organizations 
having  logistics  and  user  responsibilities  must  become  involved  early  in 
the  program. 

j.  Planning  for  DT&E  and  OT&E  will  assure  that  DT  and  OT  test  designs 
are  prepared  and  that  test  results  are  evaluated  independently. 

, 2.18  Cost  Estimates.  . . . Program  cost  estimates  must  address  all 

resources  necessary  to  develop,  procure,  operate  and  support  the 
system  and  will  be  the  fundamental  baseline  for  programming. 

a.  Initial  cost  estimates  will  be  based  on  rather  broad  outlines  of 
the  conceptual  system  and  historic  cost  data  obtained  from  similar  programs. 

c.  Baseline  cost  estimate  (BCE)  development  costs  will  be  generated 

using  the  Total  Risk  Assessing  Cost  Estimate  (TRACE)  Concept  

I (AR  11-18). 
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Figure  3.1.  Materiel  Acquisition  Process  for  Major  Systems 
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c.  Cost,  performance,  and  schedule  estimates  are  not  firm  at  this 
time  and  specific  goals  and  thresholds  will  not  be  established  at  Mile- 
stone I. 

d.  Program  management  constraints  will  be  established  by  the  Army 
and  approved  by  SECDEF  for  selected  program  factors.  When  a constraint  is 
projected  to  be  exceeded,  the  SA  will  provide  the  SECDEF  with  an  assessment 
of  the  problem  and  issues  and  the  recommended  action. 

3.6  Demonstration  and  Validation  Phase. 

a.  This  phase  of  the  acquisition  process  generally  will  be  conducted 
with  two  or  more  competitors. 

b.  Test  and  evaluation  will  be  conducted,  as  appropriate,  of  train- 
ing simulators,  test  equipment,  tools,  and  other  subsystems  in  order  that 
development  of  these  subsystems  will  parallel  the  development  of  system 

I prototypes. 

[ c.  Subsystems  selected  for  use  in  a system  acquisition  program  will 

[ not  be  fully  developed  until  the  program  has  been  approved  for  full-scale 

I engineering  development.  The  SECDEF  may  authorize  an  exception  to  this 

f policy  if  delivery  schedule  considerations  require  earlier  development  of 

f a subsystem. 

d.  Detailed  work  on  the  system  support  package  will  begin  during 
this  phase. 

e.  DT/OT  I generally  will  be  conducted  in  this  phase  to  support  a 
decision  at  Milestone  II. 

f.  COEA  will  be  updated  using  updated  threat  data,  test  data,  and 
more  detailed  cost  estimates. 

I 

i g.  The  Required  Operational  Capability  (ROC)  or  the  Letter  Require- 

ment (LR)  will  be  the  requirement  documents  supporting  work  undertaken  in 
full-scale  engineering  development  or  procurement.  The  ROC  will  specify 
the  mission  effectiveness  sought  in  terms  of  performance  parameters,  not 
in  terms  of  specific  design  features.  Performance  will  be  specified  in 
terms  of  mission  acceptable  performance  floors  and  a desired  performance 
target  (see  AR  71-9).  An  acquisition  plan  (see  AR  70-1)  will  be  developed 
as  the  materiel  developer's  management  plan  to  support  the  ROC. 

. 3. 7 Full-Scale  Engineering  Development  Decision  (Milestone  II) . When  the 

demonstration  and  validation  phase  is  completed,  approval  will  be 
sought  to  begin  full-scale  engineering  development. 

b.  The  updated  DCP  is  the  major  supporting  document  for  Milestone  II 
ASARC/DSARC  deliberations.  It  presents  the  total  program  through  procure- 
ment and  deployment. 

c.  Management  thresholds  will  be  established  at  Milestone  II  for 
selected  performance,  cost,  and  schedule  parameters. 
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3. 8  Full-Scale  Engineering  Development  Phase 
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b.  RAM  design,  testing  and  evaluation  of  components  should  be  inte- 
grated into  the  earliest  part  of  this  phase. 

c.  Design  trade-offs  will  be  implemented  in  a manner  which  gives 
optimal  overall  system  cost  effectiveness.  Simplicity  will  be  emphasized 
as  opposed  to  sophistication  and  high  priority  will  be  placed  on  ensuring 
that  adequate  quantities  of  equipment  can  be  afforded. 

e.  During  this  phase,  the  system  support  package,  to  include  integrated 
technical  documentation  and  training  (ITDT)  materials,  training  ammunition, 
training  devices,  and  automated  test  equipment,  will  be  developed  and  tested. 

f.  DT/OT  II  will  be  conducted  during  this  phase.  If  DT/OT  II  evalu- 
ation reveals  significant  deficiencies.  Including  any  in  the  system  support 
package,  design  corrections  will  be  made  and  prior  to  a production  deci- 
sion, DT/OT  Ila  will  be  conducted  as  directed  by  the  decision  authority. 

g.  COEA  will  be  updated  using  updated  threat  data,  DT/OT  II  results, 
and  updated  cost  estimates. 

3.9  Production  and  Deployment  Decision  (Milestone  III).  When  FSED  is  com- 
pleted, approval  will  be  sought  to  begin  production.  The  updated  DCP  is 

the  major  supporting  document  for  Milestone  III  ASARC/DSARC  deliberations. 

a.  Programs  will  not  be  permitted  to  enter  production  on  the  conten- 
tion that  significant  deficiencies  can  be  corrected  and  later  verified 
using  production  hardware. 

3.10  Production  and  Deployment  Phase 

a.  Successful  completion  of  DT/OT  II  and  Milestone  III  approval 
permit  production  at  rates  based  on  manufacturing  efficiency,  operational 
demand,  and  resource  availability. 


A-10 


ij 


APPENDIX  B 


I i* 

5 ¥ 

\ '• 

f i 

f >. 


LIST  OF  ABBREVIATIONS  AND  ACRONYMS 


AD  Advanced  Development 

APM  Army  Program  Memorandum 

ARTEP  Army  Training  and  Evaluation  Program 

ASARC  Army  Systems  Acquisition  Review  Council 

BCE  Baseline  Cost  Estimate 

BOI  Basis  of  Issue 

BOIP  Basis  of  Issue  Plan 

BTA  Best  Technical  Approach 

CD  Combat  Development 

CFP  Concept  Formulation  Package 

COEA  Cost  and  Operational  Effectiveness  Analysis 

CTA  Common  Table  of  Allowances 

CTEA  Cost  and  Training  Effectiveness  Analysis 

CTP  Coordinated  Test  Program 

DARCOM  Development  and  Readiness  Command 

DCD  Decision  Coordination  Document 

DCP  Decision  Coordinating  Paper 

DP  Development  Plan 

DPM  Defense  Program  Memorandum 

DSARC  Defense  Systems  Acquisition  Review  Council 

DT  Development  Testing 

DTC  Design  to  Cost 

ED  Engineering  Development 

FEA  Front  End  Analysis 

HQDA  Headquarters,  Department  of  the  Army 

ICTP  Individual/Collective  Training  Program 

ILS  Integrated  Logistics  System 

IOC  Initial  Operational  Capability 

IPR  In-Process  Review 

ISD  Instructional  System  Development 

ITDT  Integrated  Technical  Documentation  and  Training 

ITP  Individual  Training  Plan 

JPG  Job  Performance  Guide 

JPM  Job  Performance  Manual 

JWG  Joint  Working  Group 

LCSMM  Life  Cycle  System  Management  Model 

LOA  Letter  of  Agreement 

LSA  Logistics  Support  Analysis 

MENS  Mission  Element  Needs  Statement 

MOS  Military  Occupational  Specialty 

MTOE  Modification  Table  of  Organization  and  Equipment 

NET  New  Equipment  Training 

OCO  Operational  Capability  Objective 

ODP  Outline  Development  Plan 

OICTP  Outline  Individual/Collective  Training  Plan 

OSD  Office  of  the  Secretary  of  Defense 
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OT 

OTRS 

PQQPRI 

QQPRI 

RDTE 

RFP 

ROC 

SCORES 

SEC  ARMY 

SEC  DEF 

SOW 

SQT 

SSG 

STEPS 

STF 

STO 

STOG 

TAADS 

TDR 

TEC 

TFPG 

TM 

TMOS 

TOA 

TOD 

TOE 

TRADOC 

TSM 


Operational  Testing 
Operational  Test  Readiness  Statement 
Provisional  Qualitative  and  Quantitative  Personnel 
Requirements  Information 

Qualitative  and  Quantitative  Personnel  Requirements 
Information 

Research  Development  Test  and  Evaluation 

Request  for  Proposal 

Required  Operational  Capability 

Scenario  Oriented  Recurring  Evaluation  System 

Secretary  of  the  Army 

Secretary  of  the  Defense 

Statement  of  Work 

Skills  Qualification  Test 

Special  Study  Group 

Simulation  and  Training  Equipment  Sources 

Special  Task  Force 

Science  and  Technology  Objectives 

Science  and  Technology  Objective  Guides 

The  Army  Authorization  Documents  System 

Training  Device  Requirement 

Training  Extension  Course 

Task  Force  Planning  Group 

Technical  Manual 

(Tentative)  Military  Occupational  Specialty 

Trade-Off  Analysis 

Trade-Off  Determination 

Table  of  Organization  and  Equipment 

Training  and  Doctrine  Command 

TRADOC  Systems  Manager 
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Army  Regulations 

AR  11-18 
AR  15-14 
AR  70-1 
AR  70-10 

AR  70-27 

AR  71-2 
AR  71-3 
AR  71-9 
AR  310-49 
AR  350-XXX 

AR  611-1 
AR  700-127 
AR  1000-1 
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